Re: [PATCH 1/3] ARM: EXYNOS4: Modify PMU register setting function

2011-09-18 Thread Sylwester Nawrocki
Hi Jongpill,

On 09/15/2011 04:03 AM, Jongpill Lee wrote:
 This patch modifies PMU register setting function to support the other 
 Exynos4 series.
 
 Signed-off-by: Jongpill Leeboyko@samsung.com
 ---
   arch/arm/mach-exynos4/include/mach/pmu.h  |5 +
   arch/arm/mach-exynos4/include/mach/regs-pmu.h |1 -
   arch/arm/mach-exynos4/pmu.c   |  238 
 +---
   3 files changed, 94 insertions(+), 150 deletions(-)
 
 diff --git a/arch/arm/mach-exynos4/include/mach/pmu.h 
 b/arch/arm/mach-exynos4/include/mach/pmu.h
 index a952904..430e917 100644
 --- a/arch/arm/mach-exynos4/include/mach/pmu.h
 +++ b/arch/arm/mach-exynos4/include/mach/pmu.h
 @@ -20,6 +20,11 @@ enum sys_powerdown {
   NUM_SYS_POWERDOWN,
   };
 
 +struct exynos4_pmu_conf {
 + void __iomem *reg;
 + unsigned long val[NUM_SYS_POWERDOWN];

Why unsigned long? It's for the registers value, wouldn't u32 fit better?

 +};
 +
   extern void exynos4_sys_powerdown_conf(enum sys_powerdown mode);
 
   #endif /* __ASM_ARCH_PMU_H */
 diff --git a/arch/arm/mach-exynos4/include/mach/regs-pmu.h 
 b/arch/arm/mach-exynos4/include/mach/regs-pmu.h
 index cdf9b47..7fa44b9 100644
 --- a/arch/arm/mach-exynos4/include/mach/regs-pmu.h
 +++ b/arch/arm/mach-exynos4/include/mach/regs-pmu.h
 @@ -27,7 +27,6 @@
   #define S5P_USE_STANDBY_WFI1(1  17)
   #define S5P_USE_STANDBY_WFE0(1  24)
   #define S5P_USE_STANDBY_WFE1(1  25)
 -#define S5P_USE_MASK ((0x3  16) | (0x3  24))
 
   #define S5P_SWRESET S5P_PMUREG(0x0400)
 
 diff --git a/arch/arm/mach-exynos4/pmu.c b/arch/arm/mach-exynos4/pmu.c
 index 7ea9eb2..0210231 100644
 --- a/arch/arm/mach-exynos4/pmu.c
 +++ b/arch/arm/mach-exynos4/pmu.c
 @@ -16,160 +16,100 @@
   #includemach/regs-clock.h
   #includemach/pmu.h
 
 -static void __iomem *sys_powerdown_reg[] = {
 - S5P_ARM_CORE0_LOWPWR,
...
 - S5P_GPS_ALIVE_LOWPWR,
 -};
 +static struct exynos4_pmu_conf *exynos4_pmu_config;
 +
 +static unsigned int exynos4_pmu_entry_cnt;
 
 -static const unsigned int sys_powerdown_val[][NUM_SYS_POWERDOWN] = {
 - /* { AFTR, LPA, SLEEP }*/
 - { 0, 0, 2 },/* ARM_CORE0 */
...
 - { 7, 0, 0 },/* GPS_ALIVE */
 +static struct exynos4_pmu_conf exynos4210_pmu_config[] = {
 + /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
 + { S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
...
 + { S5P_GPS_ALIVE_LOWPWR, { 0x7, 0x0, 0x0 } },
   };
 
   void exynos4_sys_powerdown_conf(enum sys_powerdown mode)
   {
 - unsigned int count = ARRAY_SIZE(sys_powerdown_reg);
 + unsigned int count = exynos4_pmu_entry_cnt;

How about using a sentinel at the array end and getting rid of the global
'exynos4_pmu_entry_cnt' variable? For instance an empty entry { } ?  

 
   for (; count  0; count--)
 - __raw_writel(sys_powerdown_val[count - 1][mode],
 - sys_powerdown_reg[count - 1]);
 + __raw_writel(exynos4_pmu_config[count - 1].val[mode],
 + exynos4_pmu_config[count - 1].reg);
 +}
 +
 +static int __init exynos4_pmu_init(void)
 +{
 + exynos4_pmu_config = exynos4210_pmu_config;
 + exynos4_pmu_entry_cnt = ARRAY_SIZE(exynos4210_pmu_config);
 + printk(KERN_INFO EXYNOS4210 PMU Initialize\n);

EXYNOS4210 PMU initialized\n, EXYNOS4210 PMU initialization 
completed\n ?

Moreover AFAIK pr_info is preferred.

 +
 + return 0;
   }
 +arch_initcall(exynos4_pmu_init);

--
Thanks,
Sylwester
--
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/2] video: s3c-fb: Add window positioning support

2011-09-18 Thread Florian Tobias Schandinat
Hi Laurent,

On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
 Hi Florian,
 
 On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
 Hi all,

 On 08/25/2011 07:51 PM, Ajay Kumar wrote:
 Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
 seem to be doing window/plane positioning in their driver code.
 Is it possible to have this window positioning support at a common place?

 Good point. Congratulations for figuring out that I like to standardize
 things. But I think your suggestion is far from being enough to be useful
 for userspace (which is our goal so that applications can be reused along
 drivers and don't need to know about individual drivers).
 
 Beside standardizing things, do you also like to take them one level higher 
 to 
 solve challenging issues ? I know the answer must be yes :-)
 
 The problem at hand here is something we have solved in V4L2 (theoretically 
 only for part of it) with the media controller API, the V4L2 subdevs and 
 their 
 pad-level format API.
 
 In a nutshell, the media controller lets drivers model hardware as a graph of 
 buliding blocks connected through their pads and expose that description to 
 userspace applications. In V4L2 most of those blocks are V4L2 subdevs, which 
 are abstract building blocks that implement sets of standard operations. 
 Those 
 operations are exposed to userspace through the V4L2 subdevs pad-level format 
 API, allowing application to configure sizes and selection rectangles at all 
 pads in the graph. Selection rectangles can be used to configure cropping and 
 composing, which is exactly what the window positioning API needs to do.
 
 Instead of creating a new fbdev-specific API to do the same, shouldn't we try 
 to join forces ?

Okay, thanks for the pointer. After having a look at your API I understand that
it would solve the problem to discover how many windows (in this case) are there
and how they can be accessed. It looks fine for this purpose, powerful enough
and not too complex. So if I get it correct we still need at least a way to
configure the position of the windows/overlays/sink pads similar to what Ajay
proposed. Additionally a way to get and/or set the z-position of the overlays if
multiple overlays overlap and set/get how the overlays work (overdraw, constant
alpha, source/destination color keying). Normally I'd consider these link
properties but I think implementing them as properties of the source framebuffer
or sink pad would work as well.
Is this correct or did I miss something?


Best regards,

Florian Tobias Schandinat
--
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 v2 0/7] S3C2443/S3C2416: Implement support for ADC

2011-09-18 Thread Heiko Stübner
The adc blocks of S3C2443 and S3C2416/2450 differ in some regards
from previous (S3C2410, etc) and later (S3C64XX, S5P) SoCs.

Defining more TYPE_ADCVx types for these SoCs would complicate the
necessary checks a lot. Therefore I opted for the use of quirk
constants which can describe the features of the respective adc
block and can be tested directly against.

This patch series replaces the type checks with checks for specific
quirks and adds support for S3C2443 and S3C2416/2450 on top of this.

Each patch was compile tested, and I tried to only do equivalent
transforms for the stuff on lower levels. But as I have only
access to S3C2416 hardware, real life testing happened only there.

Changes since v1:
added a wrap for a line over 80 and moved the adc_setname call
to the s3c24XX.c files where all the other names are set.

Heiko Stuebner (7):
  S3C2443/S3C2416: Add adc registers
  s3c-adc: describe features via quirk constants
  s3c-adc: Replace TYPE_ADCVx conditionals with quirks
  s3c-adc: Fix mux bit modification in s3c_adc_select
  S3C24XX: Allow overriding of adc device name
  s3c-adc: Add support for S3C2443
  s3c-adc: Add support for S3C2416/S3C2450

 arch/arm/mach-s3c2416/s3c2416.c   |3 +
 arch/arm/mach-s3c2443/s3c2443.c   |3 +
 arch/arm/plat-samsung/adc.c   |   90 +++-
 arch/arm/plat-samsung/include/plat/adc-core.h |2 +-
 arch/arm/plat-samsung/include/plat/regs-adc.h |3 +
 5 files changed, 80 insertions(+), 20 deletions(-)

-- 
1.7.2.3

--
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 1/7] S3C2443/S3C2416: Add adc registers

2011-09-18 Thread Heiko Stübner
The adc blocks of the S3C2443 and S3C2416 define some
additional registers and bits.

Signed-off-by: Heiko Stuebner he...@sntech.de
---
 arch/arm/plat-samsung/include/plat/regs-adc.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-samsung/include/plat/regs-adc.h 
b/arch/arm/plat-samsung/include/plat/regs-adc.h
index 035e8c3..f42c445 100644
--- a/arch/arm/plat-samsung/include/plat/regs-adc.h
+++ b/arch/arm/plat-samsung/include/plat/regs-adc.h
@@ -20,6 +20,7 @@
 #define S3C2410_ADCDAT0   S3C2410_ADCREG(0x0C)
 #define S3C2410_ADCDAT1   S3C2410_ADCREG(0x10)
 #define S3C64XX_ADCUPDNS3C2410_ADCREG(0x14)
+#define S3C2443_ADCMUX S3C2410_ADCREG(0x18)
 #define S3C64XX_ADCCLRINT  S3C2410_ADCREG(0x18)
 #define S5P_ADCMUX S3C2410_ADCREG(0x1C)
 #define S3C64XX_ADCCLRINTPNDNUPS3C2410_ADCREG(0x20)
@@ -33,6 +34,7 @@
 #define S3C2410_ADCCON_PRSCVLMASK  (0xFF6)
 #define S3C2410_ADCCON_SELMUX(x)   (((x)0x7)3)
 #define S3C2410_ADCCON_MUXMASK (0x73)
+#define S3C2416_ADCCON_RESSEL  (13)
 #define S3C2410_ADCCON_STDBM   (12)
 #define S3C2410_ADCCON_READ_START  (11)
 #define S3C2410_ADCCON_ENABLE_START(10)
@@ -40,6 +42,7 @@
 
 
 /* ADCTSC Register Bits */
+#define S3C2443_ADCTSC_UD_SEN  (18)
 #define S3C2410_ADCTSC_YM_SEN  (17)
 #define S3C2410_ADCTSC_YP_SEN  (16)
 #define S3C2410_ADCTSC_XM_SEN  (15)
-- 
1.7.2.3

--
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/2] video: s3c-fb: Add window positioning support

2011-09-18 Thread Laurent Pinchart
Hi Florian,

On Sunday 18 September 2011 21:29:57 Florian Tobias Schandinat wrote:
 On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
  On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
  On 08/25/2011 07:51 PM, Ajay Kumar wrote:
  Just as a note, there are many drivers like mx3fb.c, au1200fb.c and
  OMAP seem to be doing window/plane positioning in their driver code.
  Is it possible to have this window positioning support at a common
  place?
  
  Good point. Congratulations for figuring out that I like to standardize
  things. But I think your suggestion is far from being enough to be
  useful for userspace (which is our goal so that applications can be
  reused along drivers and don't need to know about individual drivers).
  
  Beside standardizing things, do you also like to take them one level
  higher to solve challenging issues ? I know the answer must be yes :-)
  
  The problem at hand here is something we have solved in V4L2
  (theoretically only for part of it) with the media controller API, the
  V4L2 subdevs and their pad-level format API.
  
  In a nutshell, the media controller lets drivers model hardware as a
  graph of buliding blocks connected through their pads and expose that
  description to userspace applications. In V4L2 most of those blocks are
  V4L2 subdevs, which are abstract building blocks that implement sets of
  standard operations. Those operations are exposed to userspace through
  the V4L2 subdevs pad-level format API, allowing application to configure
  sizes and selection rectangles at all pads in the graph. Selection
  rectangles can be used to configure cropping and composing, which is
  exactly what the window positioning API needs to do.
  
  Instead of creating a new fbdev-specific API to do the same, shouldn't we
  try to join forces ?
 
 Okay, thanks for the pointer. After having a look at your API I understand
 that it would solve the problem to discover how many windows (in this
 case) are there and how they can be accessed. It looks fine for this
 purpose, powerful enough and not too complex. So if I get it correct we
 still need at least a way to configure the position of the
 windows/overlays/sink pads similar to what Ajay proposed.

Yes, the media controller API can only expose the topology to userspace, it 
can't be used to configure FB-specific parameters on the pipeline.

 Additionally a way to get and/or set the z-position of the overlays if
 multiple overlays overlap and set/get how the overlays work (overdraw,
 constant alpha, source/destination color keying). Normally I'd consider
 these link properties but I think implementing them as properties of the
 source framebuffer or sink pad would work as well.
 Is this correct or did I miss something?

That's correct.

What bothers me is that both V4L2 and DRM/KMS have the exact same needs. I 
don't think it makes sense to implement three different solutions to the same 
problem in our three video-related APIs. What's your opinion about that ?

I've tried to raise the issue on the dri-devel mailing list (Proposal for a 
low-level Linux display framework), but there's still a long way to go before 
convincing everybody. Feel free to help me :-)

-- 
Regards,

Laurent Pinchart
--
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 2/7] s3c-adc: describe features via quirk constants

2011-09-18 Thread Heiko Stübner
The adc blocks of S3C2410 through S5P have a multitude of
quirks, i.e. moved bits or whole new registers.

This patch tries to describe these individual features
through constants which can be used to describe an adc.

As SoCs sometimes share only some of these quirks defining
TYPE_ADCVx values for each one wouldn't scale well when
adding more variants.

Signed-off-by: Heiko Stuebner he...@sntech.de
---
 arch/arm/plat-samsung/adc.c |   29 +
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
index ee8deef..b209d58 100644
--- a/arch/arm/plat-samsung/adc.c
+++ b/arch/arm/plat-samsung/adc.c
@@ -45,6 +45,35 @@ enum s3c_cpu_type {
TYPE_ADCV3, /* S5PV210, S5PC110, EXYNOS4210 */
 };
 
+/*
+ * Resolution of the ADC - 10 or 12 bit
+ */
+#define S3C_ADC_QUIRK_10BIT0
+#define S3C_ADC_QUIRK_12BIT(10)
+
+/*
+ * 12bit ADC can switch resolution between 10 bit and 12 bit
+ * ADCCON bit 03 for S3C2416
+ * ADCCON bit 16 for S3C64XX and up
+ */
+#define S3C_ADC_QUIRK_RESSEL03 (11)
+#define S3C_ADC_QUIRK_RESSEL16 (12)
+
+/*
+ * Input channel select can either be in
+ * - reg ADCCON, bit for S3C24XX and S3C64XX
+ * - reg base+0x18 for 2443/2416/2450
+ * - reg base+0x1C for S5P
+ */
+#define S3C_ADC_QUIRK_MUXADCCON(13)
+#define S3C_ADC_QUIRK_MUX18(14)
+#define S3C_ADC_QUIRK_MUX1C(15)
+
+/*
+ * CLRINT register on S3C64xx
+ */
+#define S3C_ADC_QUIRK_CLRINT   (16)
+
 struct s3c_adc_client {
struct platform_device  *pdev;
struct list_head pend;
-- 
1.7.2.3

--
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 3/7] s3c-adc: Replace TYPE_ADCVx conditionals with quirks

2011-09-18 Thread Heiko Stübner
This patch replaces the static TYPE_ADCVs checks with checks for
specific features of an adc block. For this the s3c_cpu_type enum
in driver_data ist int containing containing the bit values
describing the indivial adc block.

This patch contains no functional changes, it merely replaces
the type checks with checks for indidual quirks.

Signed-off-by: Heiko Stuebner he...@sntech.de
---
 arch/arm/plat-samsung/adc.c |   33 +
 1 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
index b209d58..e3456d6 100644
--- a/arch/arm/plat-samsung/adc.c
+++ b/arch/arm/plat-samsung/adc.c
@@ -39,12 +39,6 @@
  * action is required.
  */
 
-enum s3c_cpu_type {
-   TYPE_ADCV1, /* S3C24XX */
-   TYPE_ADCV2, /* S3C64XX, S5P64X0, S5PC100 */
-   TYPE_ADCV3, /* S5PV210, S5PC110, EXYNOS4210 */
-};
-
 /*
  * Resolution of the ADC - 10 or 12 bit
  */
@@ -123,7 +117,7 @@ static inline void s3c_adc_select(struct adc_device *adc,
  struct s3c_adc_client *client)
 {
unsigned con = readl(adc-regs + S3C2410_ADCCON);
-   enum s3c_cpu_type cpu = platform_get_device_id(adc-pdev)-driver_data;
+   int cpu = platform_get_device_id(adc-pdev)-driver_data;
 
client-select_cb(client, 1);
 
@@ -132,7 +126,7 @@ static inline void s3c_adc_select(struct adc_device *adc,
con = ~S3C2410_ADCCON_STARTMASK;
 
if (!client-is_ts) {
-   if (cpu == TYPE_ADCV3)
+   if (cpu  S3C_ADC_QUIRK_MUX1C)
writel(client-channel  0xf, adc-regs + S5P_ADCMUX);
else
con |= S3C2410_ADCCON_SELMUX(client-channel);
@@ -308,7 +302,7 @@ static irqreturn_t s3c_adc_irq(int irq, void *pw)
 {
struct adc_device *adc = pw;
struct s3c_adc_client *client = adc-cur;
-   enum s3c_cpu_type cpu = platform_get_device_id(adc-pdev)-driver_data;
+   int cpu = platform_get_device_id(adc-pdev)-driver_data;
unsigned data0, data1;
 
if (!client) {
@@ -322,7 +316,7 @@ static irqreturn_t s3c_adc_irq(int irq, void *pw)
 
client-nr_samples--;
 
-   if (cpu != TYPE_ADCV1) {
+   if (cpu  S3C_ADC_QUIRK_12BIT) {
/* S3C64XX/S5P ADC resolution is 12-bit */
data0 = 0xfff;
data1 = 0xfff;
@@ -349,7 +343,7 @@ static irqreturn_t s3c_adc_irq(int irq, void *pw)
}
 
 exit:
-   if (cpu != TYPE_ADCV1) {
+   if (cpu  S3C_ADC_QUIRK_CLRINT) {
/* Clear ADC interrupt */
writel(0, adc-regs + S3C64XX_ADCCLRINT);
}
@@ -423,7 +417,7 @@ static int s3c_adc_probe(struct platform_device *pdev)
clk_enable(adc-clk);
 
tmp = adc-prescale | S3C2410_ADCCON_PRSCEN;
-   if (platform_get_device_id(pdev)-driver_data != TYPE_ADCV1) {
+   if (platform_get_device_id(pdev)-driver_data  S3C_ADC_QUIRK_12BIT) {
/* Enable 12-bit ADC resolution */
tmp |= S3C64XX_ADCCON_RESSEL;
}
@@ -504,7 +498,7 @@ static int s3c_adc_resume(struct device *dev)
 
tmp = adc-prescale | S3C2410_ADCCON_PRSCEN;
/* Enable 12-bit ADC resolution */
-   if (platform_get_device_id(pdev)-driver_data != TYPE_ADCV1)
+   if (platform_get_device_id(pdev)-driver_data  S3C_ADC_QUIRK_12BIT)
tmp |= S3C64XX_ADCCON_RESSEL;
writel(tmp, adc-regs + S3C2410_ADCCON);
 
@@ -519,13 +513,20 @@ static int s3c_adc_resume(struct device *dev)
 static struct platform_device_id s3c_adc_driver_ids[] = {
{
.name   = s3c24xx-adc,
-   .driver_data= TYPE_ADCV1,
+   .driver_data= S3C_ADC_QUIRK_10BIT |
+   S3C_ADC_QUIRK_MUXADCCON,
}, {
.name   = s3c64xx-adc,
-   .driver_data= TYPE_ADCV2,
+   .driver_data= S3C_ADC_QUIRK_12BIT |
+   S3C_ADC_QUIRK_MUXADCCON |
+   S3C_ADC_QUIRK_RESSEL16 |
+   S3C_ADC_QUIRK_CLRINT,
}, {
.name   = samsung-adc-v3,
-   .driver_data= TYPE_ADCV3,
+   .driver_data= S3C_ADC_QUIRK_12BIT |
+   S3C_ADC_QUIRK_MUX1C |
+   S3C_ADC_QUIRK_RESSEL16 |
+   S3C_ADC_QUIRK_CLRINT,
},
{ }
 };
-- 
1.7.2.3

--
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 4/7] s3c-adc: Fix mux bit modification in s3c_adc_select

2011-09-18 Thread Heiko Stübner
The mux bits in the adccon register should be cleared only
if muxing is really done in ADCCON and not another register.

This patch introduces a conditional for this.

Signed-off-by: Heiko Stuebner he...@sntech.de
---
 arch/arm/plat-samsung/adc.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
index e3456d6..05030ca 100644
--- a/arch/arm/plat-samsung/adc.c
+++ b/arch/arm/plat-samsung/adc.c
@@ -121,7 +121,8 @@ static inline void s3c_adc_select(struct adc_device *adc,
 
client-select_cb(client, 1);
 
-   con = ~S3C2410_ADCCON_MUXMASK;
+   if (cpu  S3C_ADC_QUIRK_MUXADCCON)
+   con = ~S3C2410_ADCCON_MUXMASK;
con = ~S3C2410_ADCCON_STDBM;
con = ~S3C2410_ADCCON_STARTMASK;
 
-- 
1.7.2.3

--
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 5/7] S3C24XX: Allow overriding of adc device name

2011-09-18 Thread Heiko Stübner
The adc blocks of S3C2443 and S3C2416 contain quirks not present
in the stock S3C24xx adc. Therefore allow them to alter the
device name via s3c_adc_setname.

Signed-off-by: Heiko Stuebner he...@sntech.de
---
 arch/arm/plat-samsung/include/plat/adc-core.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-samsung/include/plat/adc-core.h 
b/arch/arm/plat-samsung/include/plat/adc-core.h
index a281568..a927bee 100644
--- a/arch/arm/plat-samsung/include/plat/adc-core.h
+++ b/arch/arm/plat-samsung/include/plat/adc-core.h
@@ -20,7 +20,7 @@
 /* re-define device name depending on support. */
 static inline void s3c_adc_setname(char *name)
 {
-#ifdef CONFIG_SAMSUNG_DEV_ADC
+#if defined(CONFIG_SAMSUNG_DEV_ADC) || defined(CONFIG_PLAT_S3C24XX)
s3c_device_adc.name = name;
 #endif
 }
-- 
1.7.2.3

--
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 v2 6/7] s3c-adc: Add support for S3C2443

2011-09-18 Thread Heiko Stübner
The S3C2443-adc is 10 bit wide and has its mux-select
in an extra register at base+0x18

Signed-off-by: Heiko Stuebner he...@sntech.de
---
changes since v1:
 wrap line over 80 chars and move setname call

 arch/arm/mach-s3c2443/s3c2443.c |3 +++
 arch/arm/plat-samsung/adc.c |7 +++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s3c2443/s3c2443.c b/arch/arm/mach-s3c2443/s3c2443.c
index e6a28ba..11dae3e 100644
--- a/arch/arm/mach-s3c2443/s3c2443.c
+++ b/arch/arm/mach-s3c2443/s3c2443.c
@@ -41,6 +41,7 @@
 #include plat/cpu.h
 #include plat/fb-core.h
 #include plat/nand-core.h
+#include plat/adc-core.h
 
 static struct map_desc s3c2443_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
@@ -70,6 +71,8 @@ int __init s3c2443_init(void)
s3c_nand_setname(s3c2412-nand);
s3c_fb_setname(s3c2443-fb);
 
+   s3c_adc_setname(s3c2443-adc);
+
/* change WDT IRQ number */
s3c_device_wdt.resource[1].start = IRQ_S3C2443_WDT;
s3c_device_wdt.resource[1].end   = IRQ_S3C2443_WDT;
diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
index 05030ca..af16957 100644
--- a/arch/arm/plat-samsung/adc.c
+++ b/arch/arm/plat-samsung/adc.c
@@ -129,6 +129,9 @@ static inline void s3c_adc_select(struct adc_device *adc,
if (!client-is_ts) {
if (cpu  S3C_ADC_QUIRK_MUX1C)
writel(client-channel  0xf, adc-regs + S5P_ADCMUX);
+   else if (cpu  S3C_ADC_QUIRK_MUX18)
+   writel(client-channel  0xf,
+   adc-regs + S3C2443_ADCMUX);
else
con |= S3C2410_ADCCON_SELMUX(client-channel);
}
@@ -517,6 +520,10 @@ static struct platform_device_id s3c_adc_driver_ids[] = {
.driver_data= S3C_ADC_QUIRK_10BIT |
S3C_ADC_QUIRK_MUXADCCON,
}, {
+   .name   = s3c2443-adc,
+   .driver_data= S3C_ADC_QUIRK_10BIT |
+   S3C_ADC_QUIRK_MUX18,
+   }, {
.name   = s3c64xx-adc,
.driver_data= S3C_ADC_QUIRK_12BIT |
S3C_ADC_QUIRK_MUXADCCON |
-- 
1.7.2.3

--
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 v2 7/7] s3c-adc: Add support for S3C2416/S3C2450

2011-09-18 Thread Heiko Stübner
The ADC of the S3C2416/2450 SoC is 10 or 12 bit wide, has its
source selection in the register base+0x18 and its width
selection in bit 03 of the ADCCON register.

Signed-off-by: Heiko Stuebner he...@sntech.de
---
changes since v1:
move setname call
 arch/arm/mach-s3c2416/s3c2416.c |3 +++
 arch/arm/plat-samsung/adc.c |   24 +++-
 2 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-s3c2416/s3c2416.c b/arch/arm/mach-s3c2416/s3c2416.c
index 494ce91..4261bdc 100644
--- a/arch/arm/mach-s3c2416/s3c2416.c
+++ b/arch/arm/mach-s3c2416/s3c2416.c
@@ -60,6 +60,7 @@
 #include plat/iic-core.h
 #include plat/fb-core.h
 #include plat/nand-core.h
+#include plat/adc-core.h
 
 static struct map_desc s3c2416_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
@@ -97,6 +98,8 @@ int __init s3c2416_init(void)
 
s3c_fb_setname(s3c2443-fb);
 
+   s3c_adc_setname(s3c2416-adc);
+
register_syscore_ops(s3c2416_pm_syscore_ops);
register_syscore_ops(s3c24xx_irq_syscore_ops);
 
diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
index af16957..c53c509 100644
--- a/arch/arm/plat-samsung/adc.c
+++ b/arch/arm/plat-samsung/adc.c
@@ -358,6 +358,7 @@ static int s3c_adc_probe(struct platform_device *pdev)
 {
struct device *dev = pdev-dev;
struct adc_device *adc;
+   int cpu = platform_get_device_id(pdev)-driver_data;
struct resource *regs;
int ret;
unsigned tmp;
@@ -421,9 +422,12 @@ static int s3c_adc_probe(struct platform_device *pdev)
clk_enable(adc-clk);
 
tmp = adc-prescale | S3C2410_ADCCON_PRSCEN;
-   if (platform_get_device_id(pdev)-driver_data  S3C_ADC_QUIRK_12BIT) {
-   /* Enable 12-bit ADC resolution */
-   tmp |= S3C64XX_ADCCON_RESSEL;
+   /* Enable 12-bit ADC resolution */
+   if (cpu  S3C_ADC_QUIRK_12BIT) {
+   if (cpu  S3C_ADC_QUIRK_RESSEL03)
+   tmp |= S3C2416_ADCCON_RESSEL;
+   else
+   tmp |= S3C64XX_ADCCON_RESSEL;
}
writel(tmp, adc-regs + S3C2410_ADCCON);
 
@@ -491,6 +495,7 @@ static int s3c_adc_resume(struct device *dev)
struct platform_device *pdev = container_of(dev,
struct platform_device, dev);
struct adc_device *adc = platform_get_drvdata(pdev);
+   int cpu = platform_get_device_id(pdev)-driver_data;
int ret;
unsigned long tmp;
 
@@ -502,8 +507,12 @@ static int s3c_adc_resume(struct device *dev)
 
tmp = adc-prescale | S3C2410_ADCCON_PRSCEN;
/* Enable 12-bit ADC resolution */
-   if (platform_get_device_id(pdev)-driver_data  S3C_ADC_QUIRK_12BIT)
-   tmp |= S3C64XX_ADCCON_RESSEL;
+   if (cpu  S3C_ADC_QUIRK_12BIT) {
+   if (cpu  S3C_ADC_QUIRK_RESSEL03)
+   tmp |= S3C2416_ADCCON_RESSEL;
+   else
+   tmp |= S3C64XX_ADCCON_RESSEL;
+   }
writel(tmp, adc-regs + S3C2410_ADCCON);
 
return 0;
@@ -524,6 +533,11 @@ static struct platform_device_id s3c_adc_driver_ids[] = {
.driver_data= S3C_ADC_QUIRK_10BIT |
S3C_ADC_QUIRK_MUX18,
}, {
+   .name   = s3c2416-adc,
+   .driver_data= S3C_ADC_QUIRK_12BIT |
+   S3C_ADC_QUIRK_MUX18 |
+   S3C_ADC_QUIRK_RESSEL03,
+   }, {
.name   = s3c64xx-adc,
.driver_data= S3C_ADC_QUIRK_12BIT |
S3C_ADC_QUIRK_MUXADCCON |
-- 
1.7.2.3

--
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 v8 00/16] To use DMA generic APIs for Samsung DMA

2011-09-18 Thread Vinod Koul
On Wed, 2011-09-14 at 17:03 +0530, Jassi Brar wrote:
 On 14 September 2011 16:47, Vinod Koul vinod.k...@intel.com wrote:
 
  The changelog for [PATCH v8 04/16] is misleading - we don't need any
  modification for the reason mentioned in changelog. But the modification
  has positive side-effect of preventing callbacks during terminate_all which
  is no way understood from the changelog. So I would like to changelog
  corrected.
  I thought change log was correct in depicting what patch does and Boojin
  had replied I will check again...
 
 I didn't reply because I ran out of ways to explain the same thing in
 different words.
I checked again the patch, change log and your comments.
I agree with current change log, and also your observation is right but
that is just a side effect, which IMO should be best left to developer
to choose or not, in this case she ignored it

So no changes to this and I a ready to merge it to my next in a day or
two...

-- 
~Vinod

--
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