The following warning is fixed in dma.c file:
"warning: ‘dma_dmamask’ defined but not used [-Wunused-variable]"
Signed-off-by: Sachin Kamat
---
arch/arm/mach-exynos/dma.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/dma.c b/arch/arm/mach-exynos/d
On 13 March 2012 09:22, Grant Likely wrote:
> On Tue, 21 Feb 2012 10:03:26 +0530, Thomas Abraham
> wrote:
>> Add device tree based instantiation of the interrupt combiner controller.
>>
>> Cc: Grant Likely
>> Cc: Rob Herring
>> Signed-off-by: Thomas Abraham
>> ---
>> @@ -406,13 +432,33 @@ voi
On 13 March 2012 09:13, Grant Likely wrote:
> On Thu, 23 Feb 2012 18:08:08 +0530, Thomas Abraham
> wrote:
>> Add device tree based discovery support for max8997.
>>
>> Cc: MyungJoo Ham
>> Cc: Rajendra Nayak
>> Cc: Rob Herring
>> Cc: Grant Likely
>> Signed-off-by: Thomas Abraham
>> ---
>> .
The following warning is fixed in common.c file:
"warning: unused variable ‘ret’ [-Wunused-variable]"
Signed-off-by: Sachin Kamat
---
arch/arm/mach-exynos/common.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/commo
On 13 March 2012 08:58, Grant Likely wrote:
> On Thu, 23 Feb 2012 18:08:07 +0530, Thomas Abraham
> wrote:
>> Add irq domain support for max8997 interrupts. The reverse mapping method
>> used is linear mapping since the sub-drivers of max8997 such as regulator
>> and charger drivers can use the m
Hi Amit,
[snip.]
> >> +
> >> + kobject_uevent(&th_zone->therm_dev->device.kobj, KOBJ_CHANGE);
> >
> > Wouldn't it make more sense to pass the trip point id also as an 'env'
> > parameter ? This way, the user space can easily figure out which trip
> > point has been crossed.
> Its a good sugge
On 3/13/12, Sachin Kamat wrote:
> Hi Marek,
> Thanks for the patch.
>
> On 09/03/2012, Marek Szyprowski wrote:
>> Add core DRM device and alternative platform device data for FIMD DRM
>> subdriver. Based on the initial patch by Joonyoung Shim
>>
>>
>> Signed-off-by: Marek Szyprowski
>> Signed-o
Hi Marek,
On 09/03/2012, Marek Szyprowski wrote:
> Add core DRM device and alternative platform device data for FIMD DRM
> subdriver. Based on the initial patch by Joonyoung Shim
>
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/mach-exynos/Kconfig |
Hi Marek,
Thanks for the patch.
On 09/03/2012, Marek Szyprowski wrote:
> Add core DRM device and alternative platform device data for FIMD DRM
> subdriver. Based on the initial patch by Joonyoung Shim
>
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/mach-e
Hi Durgadoss,
Thanks for the detailed review.
On 12 March 2012 16:21, R, Durgadoss wrote:
> Hi Amit,
>
> Thanks for keeping this up. And Sorry for late reply.
>
>> -Original Message-
>> From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel
>> Kachhap
>> Sent: Saturda
On Tue, 21 Feb 2012 10:03:26 +0530, Thomas Abraham
wrote:
> Add device tree based instantiation of the interrupt combiner controller.
>
> Cc: Grant Likely
> Cc: Rob Herring
> Signed-off-by: Thomas Abraham
> ---
> @@ -406,13 +432,33 @@ void __init combiner_init(void __iomem *combiner_base,
>
On Thu, 23 Feb 2012 18:08:08 +0530, Thomas Abraham
wrote:
> Add device tree based discovery support for max8997.
>
> Cc: MyungJoo Ham
> Cc: Rajendra Nayak
> Cc: Rob Herring
> Cc: Grant Likely
> Signed-off-by: Thomas Abraham
> ---
> .../devicetree/bindings/regulator/max8997-pmic.txt | 134
On Thu, 23 Feb 2012 18:08:07 +0530, Thomas Abraham
wrote:
> Add irq domain support for max8997 interrupts. The reverse mapping method
> used is linear mapping since the sub-drivers of max8997 such as regulator
> and charger drivers can use the max8997 irq_domain to get the linux irq
> number for
On 02/20/2012 10:33 PM, Thomas Abraham wrote:
> Changes since v3:
> - In dt case, the use of fixed gic linux irq number to map the combiner
> interrupt output is removed. This is replaced with the interrupt number
> obtained from the gic irq domain. (Thanks to Rob Herring and Grant
> Likely f
Hi Rob/Grant,
On 23 February 2012 18:08, Thomas Abraham wrote:
> Changes since v2:
> - Atleast one voltage level has to be specfied for Buck 1/2/5 even if GPIO
> DVS option is not used (suggested by MyungJoo Ham).
> - Reworked the irq_domain support based the v5 of irq_domain generalization
> p
Hi Rob/Grant,
On 21 February 2012 10:03, Thomas Abraham wrote:
> Changes since v3:
> - In dt case, the use of fixed gic linux irq number to map the combiner
> interrupt output is removed. This is replaced with the interrupt number
> obtained from the gic irq domain. (Thanks to Rob Herring and G
For all the Samsung SoC based boards which have the platform data for
s3c-fb driver, the 'default_win' element in the platform data is removed
and the lcd panel video timing values are moved out of individual window
configuration data.
Cc: Jingoo Han
Cc: Kyungmin Park
Cc: JeongHyeon Kim
Cc: Kuk
The decision to enable or disable the data output to the lcd panel from
the controller need not be based on the value of 'default_win' element
in the platform data. Instead, the data output to the panel is enabled
if any of the windows are active, else data output is disabled.
Cc: Ben Dooks
Cc: J
The video interface timing is independent of the window setup data.
The resolution of the window can be smaller than that of the lcd
panel to which the video data is output.
So move the video timing data from the per-window setup data to the
platform specific section in the platform data. This als
Changes since v1:
- Includes all changes suggested by Jingoo Han.
- Reworked s3c-fb platform data in all Samsung SoC based board files.
This patchset rearranges the elements in the platform data of the s3c-fb
driver with the intent of adding device tree support to the driver in
subsequent patches.
Newer SoCs from the S3C24XX line, namely S3C2416/2443/2450 contain
hsspi-controllers compatible with the s3c64xx type.
The previous patches enabled platform support for it, so make the
driver also usable for the S3C24xx architecture.
Signed-off-by: Heiko Stuebner
Acked-by: Grant Likely
---
dri
This lets the s3c64xx-spi driver know the specifics of the controller-
variant and also setups the gpios and the misccr bit.
This setup is valid for all S3C24XX SoCs containing a HSSPI controller
(i.e. S3C2416/2450 and S3C2443)
Signed-off-by: Heiko Stuebner
---
changes since v1: adapt to changes
Currently usable are busclk0 and busclk2.
Signed-off-by: Heiko Stuebner
---
arch/arm/mach-s3c24xx/clock-s3c2416.c |1 +
arch/arm/mach-s3c24xx/clock-s3c2443.c |1 +
arch/arm/mach-s3c24xx/common-s3c2443.c | 15 ++-
3 files changed, 12 insertions(+), 5 deletions(-)
diff --g
The S3C_PA_SPIx constants are only used by the s3c64xx-spi driver
and don't conflict with the older SoCs as they don't support hsspi.
Signed-off-by: Heiko Stuebner
---
arch/arm/mach-s3c24xx/include/mach/map.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/m
SoCs starting with the S3C2443 contain SPI controllers compatible with the
spi-s3c64xx driver and therefore need separate dma channels for rx and tx.
This patch introduces dma channel declarations for these and changes the
dma-s3c2443.c accordingly.
None of the older SoCs use the spi-dma at all.
When the hsmmc clock lookup was changed to be lookup tables based,
it seems the S3C2443 was forgotten.
As subsequent patches will want to add more lookups to it, this
patch adds the base table with the missing hsmmc lookup.
Signed-off-by: Heiko Stuebner
---
arch/arm/mach-s3c24xx/clock-s3c2443.c
The S3C2416/S3C2443/S3C2450 SoCs contain HSSPI controllers compatible
with the ones in the S3C64xx and later.
The second patch modifying the dma selection depends on the series
enabling the dma support on the S3C2416, but as the whole s3c64xx-spi
driver needs dma support this should be ok.
Tested
Grant Likely wrote:
> On Thu, 16 Feb 2012 06:37:09 +0900, Kukjin Kim wrote:
>> From: Sangsu Park
>>
>> This patch changes to use ioremap() for EXYNOS4210
>> so that we can drop the static mapping for EXYNOS
>> SoCs.
>>
>> Note: Will be updated for all of Samsung GPIOlibs
>> to use ioremap() next t
On Thu, 16 Feb 2012 06:37:09 +0900, Kukjin Kim wrote:
> From: Sangsu Park
>
> This patch changes to use ioremap() for EXYNOS4210
> so that we can drop the static mapping for EXYNOS
> SoCs.
>
> Note: Will be updated for all of Samsung GPIOlibs
> to use ioremap() next time.
>
> Signed-off-by: Sa
On Mon, Mar 12, 2012 at 08:01:34PM +0530, Thomas Abraham wrote:
> Yes, I agree with your comment. I did refer to manuals of s3c24xx to
> Exynos to ensure that the samsung pinctrl driver is generic and
> reusable on all samsung soc's. I hope I have not missed out something
> important that would re
On Fri, Mar 09, 2012 at 09:15:24PM +0900, Cho KyongHo wrote:
> +/* We does not consider super section mapping (16MB) */
> +struct iommu_client {
> + struct list_head node;
> + struct device *dev;
> +};
> +
> +struct exynos_iommu_domain {
> + struct list_head clients; /* list of iommu_cl
On 12 March 2012 19:51, Mark Brown wrote:
> On Sun, Mar 11, 2012 at 06:16:05PM +0530, Thomas Abraham wrote:
>> The platform specific callback to setup the sdhci pin mux and pin config
>> is removed and the pinctrl subsystem interface is used to setup the
>> mux and config.
>
> You've only added pi
On 12 March 2012 18:46, Karol Lewandowski wrote:
> On 12.03.2012 06:58, Thomas Abraham wrote:
>
> Hi Thomas!
>
>> On 9 March 2012 22:34, Karol Lewandowski wrote:
>>> Reorganize driver a bit to better handle device tree-based systems:
>>>
>>> - move machine type to driver's private structure inst
On Sun, Mar 11, 2012 at 06:16:05PM +0530, Thomas Abraham wrote:
> The platform specific callback to setup the sdhci pin mux and pin config
> is removed and the pinctrl subsystem interface is used to setup the
> mux and config.
You've only added pinctrl support for Exynos but this driver is also
us
On 12.03.2012 06:58, Thomas Abraham wrote:
Hi Thomas!
> On 9 March 2012 22:34, Karol Lewandowski wrote:
>> Reorganize driver a bit to better handle device tree-based systems:
>>
>> - move machine type to driver's private structure instead of
>> quering platform device variants in runtime
>>
>
Hi Amit,
Thanks for keeping this up. And Sorry for late reply.
> -Original Message-
> From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel
> Kachhap
> Sent: Saturday, March 03, 2012 4:36 PM
> To: linux...@lists.linux-foundation.org; linux-samsung-soc@vger.kernel.org
On 03/10/2012 07:52 PM, Chenglie He wrote:
> I am doing the suspend and resume of s3cfb on exynos. the clk_on and
> clk_off just failed. I think this is a related issue.
>
Without this patch, the probe for s3cfb driver itself fails - hence what
you are seeing must be different.
> On 29 February 2
37 matches
Mail list logo
