RE: [PATCH v9 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410

[Pavel Fedin]

 Hello!

> 4. This branch is not pushed to linux-next. I will sort it out if my
> previous pull requests get in. I will be out of office for Christmas so
> depending on the timing of {arm-soc,Christmas,Kukjin} this may or may
> not go into v4.5 (yay...).
> 
> 5. If it does not get into v4.5, I will rebase it and proceed further
> for v4.6.
> 
> If you have any questions, please let me know.

 Thank you very much. No, i don't have any questions, i'm glad that my work is 
picked up and not lost, i'm just keeping an eye on it
until it goes to stable.

 P.S. Not related to these sets directly, just to note... When i was writing 
the doc for SROMc bindings, i noticed that we have two
directories for Exynos in Documentation/devicetree/bindings/arm:
1. Documentation/devicetree/bindings/arm/exynos
2. Documentation/devicetree/bindings/arm/Samsung

 In (1) we have only a single old file, shouldn't this be cleaned up and 
shouldn't this file be moved to (2)?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


--
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 v7 0/6] samsung: pmu: split up SoC specific PMU data

[pankaj.dubey]

Hi Krzysztof,

On Friday 18 December 2015 09:57 AM, Krzysztof Kozlowski wrote:
> On 18.12.2015 12:32, Pankaj Dubey wrote:
>> In this series I am splitting up SoC specific PMU configuration data into
>> mach-exynos folder itself, before moving all of them under
>> drivers/soc/samsung/. Also instead of making all changes in single patch it
>> has been broken into SoC specific patches to avoid large size of patch.
>> With this approach there will not be unwanted big churns just after
>> adding exynos-pmu under drivers/soc/samsung.
>>
>> All these patches are just refactoring to keep minimal changes while moving
>> exynos-pmu driver under drivers/soc/samsung/. Support for exynos7 PMU can
>> be added on top of it, in such a manner that for ARM64 build, ARM related
>> SoC's PMU will not get compiled and thus unnecessary increasing kernel image 
>> size.
>>
>> This series have been prepared on top of Krzysztof Kozlowski's 
>> next/stuff-late-not-split-per-branch branch, and it's just a rebase compared 
>> to
>> V6 posted and reviewed here [1]. 
>>
>> [1]: https://lkml.org/lkml/2015/11/17/15
>>
>> For testing entire patchset on Peach-Pi (Exynos5880) based chromebook for 
>> boot
>> and S2R functionality.
>>
>> Tested-by: Pankaj Dubey 
>>
>> For testing entire patchset on on Trats2 (Exynos4412, S2R, reboot, poweroff)
>> and Odroid XU3 (Exynos5422, reboot, poweroff).
>>
>> Tested-by: Krzysztof Kozlowski 
>>
>> Changes since v6:
>>  - Rebasing on top of branch provided by Krzysztof, after resolving 
>> conflicts 
>>caused due to Alim's patches for adoptation of generic syscon for 
>> poweroff, reboot.
>>  - Included Tested-by tags on individual patches as per applicability.
>>  - Dropped patches v6 [1/9], v6 [2/9] as these are already present in above 
>> mentioned branch.
>>  - Dropped patch v6 [8/9] as after Alim's patch this patch no more required.
>>
> 
> Patchset applied cleanly with:
> 1. Removal of blank lines at end of two files (they appeared in v7).
> 2. Removal of your tested-by. The author does not provide such tag
> because it is assumed that he tested it before sending. However I left
> the information about testing platform near your signed-off-by.
> 

Thanks for taking care of minor nitpicks. I will be more careful, next
time.

> You can find the patches on the same branch:
> https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/stuff-late-not-split-per-branch
> 
> I hope I will be able to push it out to arm-soc soon...
> 

Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
> 
> 
--
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] ARM: s3c: simplify s3c_irqwake_{e,}intallow definition

[Arnd Bergmann]

For a long time, gcc has warned about odd configurations on s3c64xx:

In file included from arch/arm/plat-samsung/pm.c:34:0:
arch/arm/mach-s3c64xx/include/mach/pm-core.h:61:0: warning: 
"s3c_irqwake_eintallow" redefined
 #define s3c_irqwake_eintallow ((1 << 28) - 1)
In file included from arch/arm/plat-samsung/pm.c:33:0:
arch/arm/plat-samsung/include/plat/pm.h:49:0: note: this is the location of the 
previous definition
 #define s3c_irqwake_eintallow 0

The definitions of s3c_irqwake_intallow and s3c_irqwake_eintallow are a bit 
consistent
between the various platforms. Things have become easier now that it's only 
s3c24xx
and s3c64xx that use them at all, so I've tried to rearrange the definitions to
make it more obvious what is going on.

Signed-off-by: Arnd Bergmann 
---
This fixes a very old and harmless warning, please apply to a cleanup branch
if you agree.

diff --git a/arch/arm/mach-s3c24xx/include/mach/pm-core.h 
b/arch/arm/mach-s3c24xx/include/mach/pm-core.h
index 69459dbbdcad..712333fec589 100644
--- a/arch/arm/mach-s3c24xx/include/mach/pm-core.h
+++ b/arch/arm/mach-s3c24xx/include/mach/pm-core.h
@@ -85,3 +85,17 @@ static inline void s3c_pm_arch_update_uart(void __iomem 
*regs,
 
 static inline void s3c_pm_restored_gpios(void) { }
 static inline void samsung_pm_saved_gpios(void) { }
+
+/* state for IRQs over sleep */
+
+/* default is to allow for EINT0..EINT15, and IRQ_RTC as wakeup sources
+ *
+ * set bit to 1 in allow bitfield to enable the wakeup settings on it
+*/
+#ifdef CONFIG_PM_SLEEP
+#define s3c_irqwake_intallow   (1L << 30 | 0xfL)
+#define s3c_irqwake_eintallow  (0xfff0L)
+#else
+#define s3c_irqwake_eintallow 0
+#define s3c_irqwake_intallow  0
+#endif
diff --git a/arch/arm/mach-s3c24xx/irq-pm.c b/arch/arm/mach-s3c24xx/irq-pm.c
index b91341ef2b2e..417b7a20c2d1 100644
--- a/arch/arm/mach-s3c24xx/irq-pm.c
+++ b/arch/arm/mach-s3c24xx/irq-pm.c
@@ -25,19 +25,10 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
-/* state for IRQs over sleep */
-
-/* default is to allow for EINT0..EINT15, and IRQ_RTC as wakeup sources
- *
- * set bit to 1 in allow bitfield to enable the wakeup settings on it
-*/
-
-unsigned long s3c_irqwake_intallow = 1L << 30 | 0xfL;
-unsigned long s3c_irqwake_eintallow= 0xfff0L;
-
 int s3c_irq_wake(struct irq_data *data, unsigned int state)
 {
unsigned long irqbit = 1 << data->hwirq;
diff --git a/arch/arm/mach-s3c64xx/include/mach/pm-core.h 
b/arch/arm/mach-s3c64xx/include/mach/pm-core.h
index 549dadd5f487..4a285e97afff 100644
--- a/arch/arm/mach-s3c64xx/include/mach/pm-core.h
+++ b/arch/arm/mach-s3c64xx/include/mach/pm-core.h
@@ -59,9 +59,13 @@ static inline void s3c_pm_arch_show_resume_irqs(void)
 
 /* make these defines, we currently do not have any need to change
  * the IRQ wake controls depending on the CPU we are running on */
-
+#ifdef CONFIG_PM_SLEEP
 #define s3c_irqwake_eintallow  ((1 << 28) - 1)
 #define s3c_irqwake_intallow   (~0)
+#else
+#define s3c_irqwake_eintallow 0
+#define s3c_irqwake_intallow  0
+#endif
 
 static inline void s3c_pm_arch_update_uart(void __iomem *regs,
   struct pm_uart_save *save)
diff --git a/arch/arm/plat-samsung/include/plat/pm.h 
b/arch/arm/plat-samsung/include/plat/pm.h
index 7f415ce74591..9dd562ab0841 100644
--- a/arch/arm/plat-samsung/include/plat/pm.h
+++ b/arch/arm/plat-samsung/include/plat/pm.h
@@ -41,14 +41,6 @@ static inline int s3c64xx_pm_init(void)
 extern unsigned long s3c_irqwake_intmask;
 extern unsigned long s3c_irqwake_eintmask;
 
-/* IRQ masks for IRQs allowed to go to sleep (see irq.c) */
-extern unsigned long s3c_irqwake_intallow;
-#ifdef CONFIG_PM_SLEEP
-extern unsigned long s3c_irqwake_eintallow;
-#else
-#define s3c_irqwake_eintallow 0
-#endif
-
 /* per-cpu sleep functions */
 
 extern void (*pm_cpu_prep)(void);

--
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] ARM: s3c64xx: fix pm-debug compilation

[Arnd Bergmann]

I got one randconfig build that failed to compile plat-samsung/pm-debug.c
on s3c64xx:

In file included from arch/arm/plat-samsung/pm-debug.c:27:0:
arch/arm/mach-s3c64xx/include/mach/pm-core.h: In function 
's3c_pm_debug_init_uart':
arch/arm/mach-s3c64xx/include/mach/pm-core.h:25:25: error: 'S3C_VA_SYS' 
undeclared (first use in this function)
  u32 tmp = __raw_readl(S3C_PCLK_GATE);
arch/arm/mach-s3c64xx/include/mach/pm-core.h:25:25: note: each undeclared 
identifier is reported only once for each function it appears in
arch/arm/mach-s3c64xx/include/mach/pm-core.h:39:2: error: implicit declaration 
of function 'udelay' [-Werror=implicit-function-declaration]
  udelay(10);

I have not investigated why this does not show up much more often, I
guess the headers are usually included from elsewhere, but adding
explicit #include statements is an obvious fix.

Signed-off-by: Arnd Bergmann 
---
I suspect this has been broken for a long time, so no rush, but please
apply this to a cleanup branch.

diff --git a/arch/arm/mach-s3c64xx/include/mach/pm-core.h 
b/arch/arm/mach-s3c64xx/include/mach/pm-core.h
index 5be8fe368e54..4a285e97afff 100644
--- a/arch/arm/mach-s3c64xx/include/mach/pm-core.h
+++ b/arch/arm/mach-s3c64xx/include/mach/pm-core.h
@@ -16,9 +16,11 @@
 #define __MACH_S3C64XX_PM_CORE_H __FILE__
 
 #include 
+#include 
 
 #include 
 #include 
+#include 
 
 static inline void s3c_pm_debug_init_uart(void)
 {

--
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 32/69] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

[Daniel Lezcano]

Let the platform's Kconfig to select the clock instead of having a reverse
dependency from the driver to the platform options.

Add the COMPILE_TEST option for the compilation test coverage. Due to the
non portable 'delay' code, this driver is only compilable on ARM.

Signed-off-by: Daniel Lezcano 
Tested-by: Krzysztof Kozlowski 
Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Chanwoo Choi 
---
 arch/arm/mach-exynos/Kconfig | 1 +
 drivers/clocksource/Kconfig  | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 3a10f1a..ff10539 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -27,6 +27,7 @@ menuconfig ARCH_EXYNOS
select SRAM
select THERMAL
select MFD_SYSCON
+   select CLKSRC_EXYNOS_MCT
help
  Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
 
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index e3ba5b4..2062783 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -231,8 +231,8 @@ config CLKSRC_METAG_GENERIC
  This option enables support for the Meta per-thread timers.
 
 config CLKSRC_EXYNOS_MCT
-   def_bool y if ARCH_EXYNOS
-   depends on !ARM64
+   bool "Exynos multi core timer driver" if COMPILE_TEST
+   depends on ARM
help
  Support for Multi Core Timer controller on Exynos SoCs.
 
-- 
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 v4 00/58] mtd: nand: refactor the NAND subsystem (part 1)

[Brian Norris]

Hi,

On Thu, Dec 10, 2015 at 08:59:44AM +0100, Boris Brezillon wrote:
> Hello,
> 
> This huge series aims at clarifying the relationship between the mtd and
> nand_chip structures and hiding NAND framework internals to NAND
> controller drivers.
> 
> The first part of the series (patch 1 to 4) is a set of fixes/simple
> reworks easing the migration to mtd_to_nand().
> 
> The second part of the series embeds the mtd structure into the nand_chip
> one so that NAND controller drivers don't have to bother allocating the
> MTD device and linking it with the NAND chip.
> 
> The last part of the series hides accesses to the chip->priv field behind
> two helper functions.
> 
> This allows removal of some of the boilerplate code done in all NAND
> controller drivers, but most importantly, it unifies a bit the way NAND
> chip structures are instantiated (even though we still have two different
> kinds of drivers: those embedding the nand_chip struct into their private
> nand chip representation, and those allocating two different structures
> and linking them together with the chip->priv field).
> 
> As said in the title, this refactoring is only the first step. I plan to
> rework the NAND controller / NAND chip separation for pretty much the same
> reasons: clarifying the separation between the two concepts, and getting
> rid of more boilerplate code in NAND controller drivers.
> 
> Stay tuned ;-).
> 
> Best Regards,
> 
> Boris

Thanks a lot for all the work here! Nice cleanups. I think I've pushed
everything correctly to l2-mtd.git. Please verify that things look sane
to you, if possible. There were a few v5's thrown in after the fact, as
well as other cleanups that required apply-conflicts.

I'll summarize below anything I remember that's changed since the cover
letter, for posterity.

> Changes since v3:
> - fix some bugs introduced when migrating to nand_to_mtd()
> - split the huge commit switching all drivers to nand_to_mtd() into several
>   commits (one per driver) to ease review and integration
> - add a simple fixes/reworks at the beginning of the series (mainly to
>   ease migration to nand_to_mtd())
> - drop already applied patches.
> 
> Changes since v2:
> - fix some build warnings/erros
> 
> Changes since v1:
> - dropped already applied patches
> - fixed some typos
> - manually fixed some modifications omitted by the coccinelle scripts
> - manually reworked modifactions done by coccinelle scripts to improve
>   readability and fix coding style issues
> 
> *** BLURB HERE ***

Nice blurb :)

> 
> Boris Brezillon (58):
>   mtd: nand: denali: add missing nand_release() call in denali_remove()

You sent v5 of this, and I added in the comment that was
written/requested afterward. That caused some small conflicts later.

>   mtd: nand: fsmc: create and use mtd_to_fsmc()
>   mtd: nand: nuc900: create and use mtd_to_nuc900()
>   mtd: nand: omap2: create and use mtd_to_omap()
>   mtd: nand: ams-delta: use the mtd instance embedded in struct
> nand_chip
>   mtd: nand: atmel: use the mtd instance embedded in struct nand_chip
>   mtd: nand: au1550nd: use the mtd instance embedded in struct nand_chip
>   mtd: nand: bcm47xx: use the mtd instance embedded in struct nand_chip
>   mtd: nand: bf5xx: use the mtd instance embedded in struct nand_chip
>   mtd: nand: brcm: use the mtd instance embedded in struct nand_chip
>   mtd: nand: cafe: use the mtd instance embedded in struct nand_chip
>   mtd: nand: cmx270: use the mtd instance embedded in struct nand_chip

^^ I dropped one comment in this one

>   mtd: nand: cs553x: use the mtd instance embedded in struct nand_chip
>   mtd: nand: davinci: use the mtd instance embedded in struct nand_chip
>   mtd: nand: denali: use the mtd instance embedded in struct nand_chip

You sent v5, but there were still trivial conflicts.

>   mtd: nand: diskonchip: use the mtd instance embedded in struct
> nand_chip
>   mtd: nand: docg4: use the mtd instance embedded in struct nand_chip

I cleaned some things up after this one, causing more trivial conflicts
later in the controller_data accessor patches.

>   mtd: nand: fsl_elbc: use the mtd instance embedded in struct nand_chip
>   mtd: nand: fsl_ifc: use the mtd instance embedded in struct nand_chip
>   mtd: nand: fsl_upm: use the mtd instance embedded in struct nand_chip
>   mtd: nand: fsmc: use the mtd instance embedded in struct nand_chip
>   mtd: nand: gpio: use the mtd instance embedded in struct nand_chip
>   mtd: nand: gpmi: use the mtd instance embedded in struct nand_chip
>   mtd: nand: hisi504: use the mtd instance embedded in struct nand_chip
>   mtd: nand: jz4740: use the mtd instance embedded in struct nand_chip
>   mtd: nand: lpc32xx: use the mtd instance embedded in struct nand_chip
>   mtd: nand: mpc5121: use the mtd instance embedded in struct nand_chip
>   mtd: nand: mxc: use the mtd instance embedded in struct nand_chip
>   mtd: nand: nandsim: use the mtd instance embedded in struct nand_chip
>   mtd: nand: ndfc: 

Re: [PATCH v4 55/58] mtd: nand: add helpers to access ->priv

[Brian Norris]

Hi Boris,

On Thu, Dec 10, 2015 at 09:00:39AM +0100, Boris Brezillon wrote:
> Add two helpers to access the field reserved for private controller data.
> This makes it clearer what this field is reserved for and ease future
> refactoring.

I agree with the refactoring part, but I'm not sure about the name. Is
it really "controller" data? That sounds like something that has 1
instance per controller. But the way this is sometimes used, we get 1
instance per NAND chip, and there may be more than one NAND chip per
controller.

So at the moment, this is more like opaque "driver data", like
dev_{get,set}_drvdata(), which doesn't really have a prescribed use --
it's up to the driver.

Notably, we already have a (sort of) 1-per-controler-instance field:
struct nand_hw_control (I notice we have both the 'controller' and
'hwcontrol' fields in nand_chip; that's pretty ugly too...). Those don't
have private data fields, but we could of course extend that if we
really want "controller" data.

Anyway, I don't feel like this question is resolved well enough to say
that we should go change all drivers to use these accessors. I know you
have bigger plans for putting more "controller" infrastructure into the
core drivers/mtd/nand/ code, so I'd like to see how that fits in here.

(If we're going to discuss this much more, I'd suggest a smaller CC
list. I'm mostly putting this here to show why I'm not taking the last
4 patches right now.)

Regards,
Brian

> Signed-off-by: Boris Brezillon 
> ---
>  include/linux/mtd/nand.h | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 2bee2e4..4aed4b2 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -739,6 +739,16 @@ static inline struct mtd_info *nand_to_mtd(struct 
> nand_chip *chip)
>   return >mtd;
>  }
>  
> +static inline void *nand_get_controller_data(struct nand_chip *chip)
> +{
> + return chip->priv;
> +}
> +
> +static inline void nand_set_controller_data(struct nand_chip *chip, void 
> *priv)
> +{
> + chip->priv = priv;
> +}
> +
>  /*
>   * NAND Flash Manufacturer ID Codes
>   */
> -- 
> 2.1.4
> 
--
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