Re: [PATCH v3] clk: s3c2410: removed unneeded variable in s3c24xx_clkout_set_parent

2015-11-30 Thread Uwe Kleine-König
On Mon, Nov 30, 2015 at 07:52:22AM +, Mutharaju, Prasanna (P.) wrote:
> From: Prasanna Karthik <mkart...@visteon.com>
> 
> Remove unneeded variable used to store return value.
> ---
> v3: Modified subject and changelog comments
> ---
> 
> Signed-off-by: Prasanna Karthik <mkart...@visteon.com>

Everything after the first triple-dash doesn't make it into the git
history, so you are expected to write the S-o-b line above the list of
things changed since a previous submission.

Other than that the patch looks fine.

Uwe

-- 
Pengutronix e.K.       | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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] Watchdog: Fix parent of watchdog_devices

2015-08-19 Thread Uwe Kleine-König
Hello,

On Wed, Aug 19, 2015 at 08:58:24AM +0530, Pratyush Anand wrote:
 /sys/class/watchdog/watchdogn/device/modalias can help to identify the
 driver/module for a given watchdog node. However, many wdt devices does not 
 set

s/es//

 its parent and so, we do not see an entry for device in sysfs for such 
 devices.
 
 This patch fixes parent of watchdog_device so that
 /sys/class/watchdog/watchdogn/device is populated.
 
 Exceptions: booke, diag288, mpc8xxx, octeon, softdog and w83627hf -- They do 
 not
 have any parent. Not sure, how we can we identify driver for these devices.

I don't see why you don't use the platform device as parent for mpc8xxx.

Note however that I did several updates to the mpc8xxx driver which
probably conflict with setting the parent. I'll take care of that.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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] clk: make several parent names const

2015-05-28 Thread Uwe Kleine-König
Since commit 2893c379461a (clk: make strings in parent name arrays
const) the name of parent clocks can be const. So add more const in
several clock drivers.

Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
Hello,

commit 2893c379461a isn't in Linus Torvald's tree yet, so the commit
message needs adaption if clk-next is rewritten.

Should I split this patch per subdir?

Best regards
Uwe

 drivers/clk/hisilicon/clk-hi3620.c   | 70 ++--
 drivers/clk/hisilicon/clk-hix5hd2.c  |  6 +--
 drivers/clk/hisilicon/clk.h  |  2 +-
 drivers/clk/mxs/clk-imx23.c  | 12 ++---
 drivers/clk/mxs/clk-imx28.c  | 18 
 drivers/clk/mxs/clk.h|  2 +-
 drivers/clk/pxa/clk-pxa.h|  2 +-
 drivers/clk/rockchip/clk-cpu.c   |  2 +-
 drivers/clk/rockchip/clk-mmc-phase.c |  2 +-
 drivers/clk/rockchip/clk-pll.c   |  8 ++--
 drivers/clk/rockchip/clk.c   |  8 ++--
 drivers/clk/rockchip/clk.h   | 20 
 drivers/clk/samsung/clk-pll.c|  4 +-
 drivers/clk/samsung/clk-s5pv210.c| 88 ++--
 drivers/clk/samsung/clk.c| 13 +++---
 drivers/clk/samsung/clk.h| 18 
 drivers/clk/zynq/clkc.c  | 25 ++
 17 files changed, 154 insertions(+), 146 deletions(-)

diff --git a/drivers/clk/hisilicon/clk-hi3620.c 
b/drivers/clk/hisilicon/clk-hi3620.c
index 472dd2cb10b3..715d34a5ef9b 100644
--- a/drivers/clk/hisilicon/clk-hi3620.c
+++ b/drivers/clk/hisilicon/clk-hi3620.c
@@ -38,44 +38,44 @@
 #include clk.h
 
 /* clock parent list */
-static const char *timer0_mux_p[] __initdata = { osc32k, timerclk01, };
-static const char *timer1_mux_p[] __initdata = { osc32k, timerclk01, };
-static const char *timer2_mux_p[] __initdata = { osc32k, timerclk23, };
-static const char *timer3_mux_p[] __initdata = { osc32k, timerclk23, };
-static const char *timer4_mux_p[] __initdata = { osc32k, timerclk45, };
-static const char *timer5_mux_p[] __initdata = { osc32k, timerclk45, };
-static const char *timer6_mux_p[] __initdata = { osc32k, timerclk67, };
-static const char *timer7_mux_p[] __initdata = { osc32k, timerclk67, };
-static const char *timer8_mux_p[] __initdata = { osc32k, timerclk89, };
-static const char *timer9_mux_p[] __initdata = { osc32k, timerclk89, };
-static const char *uart0_mux_p[] __initdata = { osc26m, pclk, };
-static const char *uart1_mux_p[] __initdata = { osc26m, pclk, };
-static const char *uart2_mux_p[] __initdata = { osc26m, pclk, };
-static const char *uart3_mux_p[] __initdata = { osc26m, pclk, };
-static const char *uart4_mux_p[] __initdata = { osc26m, pclk, };
-static const char *spi0_mux_p[] __initdata = { osc26m, rclk_cfgaxi, };
-static const char *spi1_mux_p[] __initdata = { osc26m, rclk_cfgaxi, };
-static const char *spi2_mux_p[] __initdata = { osc26m, rclk_cfgaxi, };
+static const char *const timer0_mux_p[] __initconst = { osc32k, 
timerclk01, };
+static const char *const timer1_mux_p[] __initconst = { osc32k, 
timerclk01, };
+static const char *const timer2_mux_p[] __initconst = { osc32k, 
timerclk23, };
+static const char *const timer3_mux_p[] __initconst = { osc32k, 
timerclk23, };
+static const char *const timer4_mux_p[] __initconst = { osc32k, 
timerclk45, };
+static const char *const timer5_mux_p[] __initconst = { osc32k, 
timerclk45, };
+static const char *const timer6_mux_p[] __initconst = { osc32k, 
timerclk67, };
+static const char *const timer7_mux_p[] __initconst = { osc32k, 
timerclk67, };
+static const char *const timer8_mux_p[] __initconst = { osc32k, 
timerclk89, };
+static const char *const timer9_mux_p[] __initconst = { osc32k, 
timerclk89, };
+static const char *const uart0_mux_p[] __initconst = { osc26m, pclk, };
+static const char *const uart1_mux_p[] __initconst = { osc26m, pclk, };
+static const char *const uart2_mux_p[] __initconst = { osc26m, pclk, };
+static const char *const uart3_mux_p[] __initconst = { osc26m, pclk, };
+static const char *const uart4_mux_p[] __initconst = { osc26m, pclk, };
+static const char *const spi0_mux_p[] __initconst = { osc26m, rclk_cfgaxi, 
};
+static const char *const spi1_mux_p[] __initconst = { osc26m, rclk_cfgaxi, 
};
+static const char *const spi2_mux_p[] __initconst = { osc26m, rclk_cfgaxi, 
};
 /* share axi parent */
-static const char *saxi_mux_p[] __initdata = { armpll3, armpll2, };
-static const char *pwm0_mux_p[] __initdata = { osc32k, osc26m, };
-static const char *pwm1_mux_p[] __initdata = { osc32k, osc26m, };
-static const char *sd_mux_p[] __initdata = { armpll2, armpll3, };
-static const char *mmc1_mux_p[] __initdata = { armpll2, armpll3, };
-static const char *mmc1_mux2_p[] __initdata = { osc26m, mmc1_div, };
-static const char *g2d_mux_p[] __initdata = { armpll2, armpll3, };
-static const char *venc_mux_p[] __initdata = { armpll2, armpll3, };
-static const char *vdec_mux_p[] __initdata = { armpll2, armpll3, };
-static const char *vpp_mux_p[] __initdata

Re: [PATCH] i2c: exynos5: Move initialization code to subsys_initcall()

2015-01-11 Thread Uwe Kleine-König
Hello,

On Mon, Jan 12, 2015 at 11:53:02AM +0900, Joonyoung Shim wrote:
 This is required in order to ensure that core system devices such as
 voltage regulators attached via I2C are available early in boot.
Deferred probing isn't an option? If so I suggest adding the reasoning
in a comment to stop the next person converting it to that.
(And if not, please fix accordingly to use deferred probing.)

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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: DT on s3c24xx

2014-12-17 Thread Uwe Kleine-König
Hello,

[Cc += linusw, linux-gpio]

On Wed, Dec 17, 2014 at 10:04:24PM +0300, Vasily Khoruzhick wrote:
 I'd like to port several s3c24xx to DT, and I'm stuck with s3c24xx LCD
 controller and power drivers for H1940 and RX1950.
 
 Please see [1]. I want to move this function into another LCD power
 driver, but I'm not sure what to do with s3c_gpio_cfgpin(). I need to
 change pin function in runtime, and as far as I understand it should
 be handled via pinctrl driver somehow. But how?
You can pass 1 pinctrl setups to a node:

somedevice {
pinctrl-names = default, foo, bar;
pinctrl-0 = pinctrl_somedevice_default;
pinctrl-1 = pinctrl_somedevice_foo;
pinctrl-2 = pinctrl_somedevice_bar;
cfg-gpios = gpio4 12 3, gpio2 7 5;
};

Then I think you can fiddle with pinctrl_select_state(). For the gpios
you can then use the standard gpiod_{request,direction_{in,out}put}
combo.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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] ASoC: rt5631: Fixing compilation warning when DT is disabled

2014-11-17 Thread Uwe Kleine-König
On Mon, Nov 17, 2014 at 07:26:29PM +0530, Krishna Mohan Dani wrote:
 Fixes the following compilation warning:
 Warning: 'rt5631_i2c_dt_ids' defined but not used - when DT is not used.
 
 Signed-off-by: Claude Youn claude.y...@gmail.com
 Signed-off-by: Krishna Mohan Dani krishna...@samsung.com
 ---
  sound/soc/codecs/rt5631.c |2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/sound/soc/codecs/rt5631.c b/sound/soc/codecs/rt5631.c
 index 3b7d5e4..9425545 100644
 --- a/sound/soc/codecs/rt5631.c
 +++ b/sound/soc/codecs/rt5631.c
 @@ -1691,12 +1691,14 @@ static const struct i2c_device_id rt5631_i2c_id[] = {
  };
  MODULE_DEVICE_TABLE(i2c, rt5631_i2c_id);
  
 +#ifdef CONFIG_OF
  static struct of_device_id rt5631_i2c_dt_ids[] = {
   { .compatible = realtek,rt5631},
   { .compatible = realtek,alc5631},
   { }
  };
  MODULE_DEVICE_TABLE(of, rt5631_i2c_dt_ids);
 +#endif

An (IMHO nicer) alternative is:

-static struct of_device_id rt5631_i2c_dt_ids[] = {
+static struct of_device_id rt5631_i2c_dt_ids[] __maybe_unused = {

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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: Samsung/S3C6410/Mini6410: how to handle NAND's clock off

2014-11-12 Thread Uwe Kleine-König
Hello again,

[extending audience a bit]

On Tue, Nov 11, 2014 at 07:42:26PM +0100, Uwe Kleine-König wrote:
 On Tue, Nov 11, 2014 at 07:10:33PM +0100, Juergen Borleis wrote:
  Hi,
  
  the S3C2410 NAND driver [1] can still be used for NANDs attached to an 
  S3C6410
  SoC. But this driver has a nice feature called clock off to save some
  power while not in use. I tried it here on my Mini6410 platform and it 
  freezes
  the system.
  
  The clock tree is somehow:
  
  [...]
hclk  44   13300  0 0
   hclk_mfc   00   13300  0 0
   hclk_mem0  22   13300  0 0
  mem0_srom   00   13300  0 0
  mem0_nfcon  11   13300  0 0
  mem0_onenand0   00   13300  0 0
  mem0_onenand1   00   13300  0 0
  mem0_cfcon  00   13300  0 0
  [...]
  
  On the Mini6410 the mem0_nfcon clock is the only single user of the
  hclk_mem0. And this clock is required to keep the access to the external
  network device enabled. When the NAND driver disables its clock 
  mem0_nfcon,
  the hclk_mem0 gets also disabled because there is no consumer anymore. The
  next time the network driver tries to access its device, the SoC freezes.
 Sounds like the network driver should hold a reference to hclk_mem0.
After talking to Jürgen by phone, the solution that the dm9000 driver
should handle the clock sounds wrong. The clk in question is needed by
the SoC to operate the bus the dm9000 is connected to. So I think the
right approach would include

diff --git a/arch/arm/boot/dts/s3c6410-mini6410.dts 
b/arch/arm/boot/dts/s3c6410-mini6410.dts
index 57e00f9bce99..b5067e631216 100644
--- a/arch/arm/boot/dts/s3c6410-mini6410.dts
+++ b/arch/arm/boot/dts/s3c6410-mini6410.dts
@@ -55,9 +55,11 @@
srom-cs1@1800 {
compatible = simple-bus;
#address-cells = 1;
#size-cells = 1;
+   clock-names = hclk-whatever;
+   clocks = no_idea_which_device MEM0_SROM;
reg = 0x1800 0x800;
ranges;
 
ethernet@1800 {
compatible = davicom,dm9000;

I don't think the simple bus has clock handling, and I'm not sure if
simple bus is intended to be too simple to handle that. Anyhow, it would
describe the hardware.
The next thing that will pop up once simple-bus (or a dedicated
whatever-bus) has clk-handling is power management. Does the bus notice
when all it's devices are suspended such that the bus driver can turn
off its clock?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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: Samsung/S3C6410/Mini6410: how to handle NAND's clock off

2014-11-11 Thread Uwe Kleine-König
On Tue, Nov 11, 2014 at 07:10:33PM +0100, Juergen Borleis wrote:
 Hi,
 
 the S3C2410 NAND driver [1] can still be used for NANDs attached to an S3C6410
 SoC. But this driver has a nice feature called clock off to save some
 power while not in use. I tried it here on my Mini6410 platform and it freezes
 the system.
 
 The clock tree is somehow:
 
 [...]
   hclk  44   13300  0 0
  hclk_mfc   00   13300  0 0
  hclk_mem0  22   13300  0 0
 mem0_srom   00   13300  0 0
 mem0_nfcon  11   13300  0 0
 mem0_onenand0   00   13300  0 0
 mem0_onenand1   00   13300  0 0
 mem0_cfcon  00   13300  0 0
 [...]
 
 On the Mini6410 the mem0_nfcon clock is the only single user of the
 hclk_mem0. And this clock is required to keep the access to the external
 network device enabled. When the NAND driver disables its clock mem0_nfcon,
 the hclk_mem0 gets also disabled because there is no consumer anymore. The
 next time the network driver tries to access its device, the SoC freezes.
Sounds like the network driver should hold a reference to hclk_mem0. I
assume the system uses a device tree? This is the dm9000 driver? It
doesn't seem to use clk stuff, but it should be possible to add an
optional clk entry.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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] clk: don't use __initconst for non-const arrays

2014-09-12 Thread Uwe Kleine-König
Hello Ard,

On Fri, Sep 12, 2014 at 09:42:29AM +0200, Ard Biesheuvel wrote:
 On 12 September 2014 00:04, Uwe Kleine-König
 u.kleine-koe...@pengutronix.de wrote:
  Hello,
 
  On Thu, Sep 11, 2014 at 11:04:31PM +0200, Uwe Kleine-König wrote:
   /* Mux parent lists. */
  -static const char *fin_pll_p[] __initconst = {
  +static const char *fin_pll_p[] __initdata = {
xxti,
xusbxti
   };
  As discussed with Tomasz on irc: The sad thing here is that for this
  array only 8 bytes are freed when .init.rodata is thrown away (that is
  two pointers). The actual data---5 + 8 bytes + maybe aligning---isn't
  freed though.
 
  We wondered if there is a nice and easy way to throw away the
  characters, too.
 
  The only way I currently see is:
 
  const char xxti[] __initconst = xxti;
  ...
 
  static const char *fin_pll_p[] __initdata = {
  xxti,
  ...
  };
 
  but this definitively doesn't qualify as nice and easy. Is there an
  alternative?
 
 
 What about doing
 
 static const char fin_pll_p[][8] __initconst = {
  xxti,
  xusbxti
 };
This results in the strings being moved to .init.rodata and so they are
discarded. But it also results in:

drivers/clk/samsung/clk-s5pv210.c:412:2: warning: initialization from 
incompatible pointer type [enabled by default]
  MUX_F(FIN_PLL, fin_pll, fin_pll_p, OM_STAT, 0, 1,
  ^
drivers/clk/samsung/clk-s5pv210.c:412:2: warning: (near initialization 
for 'early_mux_clks[0].parent_names') [enabled by default]

That's because early_mux_clks[0].parent_names is of type const char **
while fin_pll_p as suggested doesn't provide an array of pointers to the
start of the contained strings.
I don't see a way to fix that unless we fix the maximal clock name
length globally and so waste much memory.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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] clk: don't use __initconst for non-const arrays

2014-09-11 Thread Uwe Kleine-König
The statement

static const char *name[];

defines a modifiable array of pointers to constant chars. That is

*name[0] = 'f';

is forbidden, but

name[0] = f;

is not. So marking an array that is defined as above with __initconst is
wrong. Either an additional const must be added such that the whole
definition reads:

static const char *const name[] __initconst;

or where this is not possible __initdata must be used.

Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
 drivers/clk/hisilicon/clk-hix5hd2.c |  6 ++--
 drivers/clk/mxs/clk-imx23.c | 12 
 drivers/clk/mxs/clk-imx28.c | 18 ++--
 drivers/clk/rockchip/clk.h  |  2 +-
 drivers/clk/samsung/clk-s5pv210.c   | 56 ++---
 drivers/clk/ti/composite.c  |  2 +-
 6 files changed, 48 insertions(+), 48 deletions(-)

diff --git a/drivers/clk/hisilicon/clk-hix5hd2.c 
b/drivers/clk/hisilicon/clk-hix5hd2.c
index e5fcfb4e32ef..7acae2eeb490 100644
--- a/drivers/clk/hisilicon/clk-hix5hd2.c
+++ b/drivers/clk/hisilicon/clk-hix5hd2.c
@@ -44,15 +44,15 @@ static struct hisi_fixed_rate_clock 
hix5hd2_fixed_rate_clks[] __initdata = {
{ HIX5HD2_FIXED_83M, 83m, NULL, CLK_IS_ROOT, 8333, },
 };
 
-static const char *sfc_mux_p[] __initconst = {
+static const char *sfc_mux_p[] __initdata = {
24m, 150m, 200m, 100m, 75m, };
 static u32 sfc_mux_table[] = {0, 4, 5, 6, 7};
 
-static const char *sdio1_mux_p[] __initconst = {
+static const char *sdio1_mux_p[] __initdata = {
75m, 100m, 50m, 15m, };
 static u32 sdio1_mux_table[] = {0, 1, 2, 3};
 
-static const char *fephy_mux_p[] __initconst = { 25m, 125m};
+static const char *fephy_mux_p[] __initdata = { 25m, 125m};
 static u32 fephy_mux_table[] = {0, 1};
 
 
diff --git a/drivers/clk/mxs/clk-imx23.c b/drivers/clk/mxs/clk-imx23.c
index 9fc9359f5133..22d136aa699f 100644
--- a/drivers/clk/mxs/clk-imx23.c
+++ b/drivers/clk/mxs/clk-imx23.c
@@ -77,12 +77,12 @@ static void __init clk_misc_init(void)
writel_relaxed(30  BP_FRAC_IOFRAC, FRAC + SET);
 }
 
-static const char *sel_pll[]  __initconst = { pll, ref_xtal, };
-static const char *sel_cpu[]  __initconst = { ref_cpu, ref_xtal, };
-static const char *sel_pix[]  __initconst = { ref_pix, ref_xtal, };
-static const char *sel_io[]   __initconst = { ref_io, ref_xtal, };
-static const char *cpu_sels[] __initconst = { cpu_pll, cpu_xtal, };
-static const char *emi_sels[] __initconst = { emi_pll, emi_xtal, };
+static const char *sel_pll[]  __initdata = { pll, ref_xtal, };
+static const char *sel_cpu[]  __initdata = { ref_cpu, ref_xtal, };
+static const char *sel_pix[]  __initdata = { ref_pix, ref_xtal, };
+static const char *sel_io[]   __initdata = { ref_io, ref_xtal, };
+static const char *cpu_sels[] __initdata = { cpu_pll, cpu_xtal, };
+static const char *emi_sels[] __initdata = { emi_pll, emi_xtal, };
 
 enum imx23_clk {
ref_xtal, pll, ref_cpu, ref_emi, ref_pix, ref_io, saif_sel,
diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
index a6c35010e4e5..b1be3746ce95 100644
--- a/drivers/clk/mxs/clk-imx28.c
+++ b/drivers/clk/mxs/clk-imx28.c
@@ -125,15 +125,15 @@ static void __init clk_misc_init(void)
writel_relaxed(val, FRAC0);
 }
 
-static const char *sel_cpu[]  __initconst = { ref_cpu, ref_xtal, };
-static const char *sel_io0[]  __initconst = { ref_io0, ref_xtal, };
-static const char *sel_io1[]  __initconst = { ref_io1, ref_xtal, };
-static const char *sel_pix[]  __initconst = { ref_pix, ref_xtal, };
-static const char *sel_gpmi[] __initconst = { ref_gpmi, ref_xtal, };
-static const char *sel_pll0[] __initconst = { pll0, ref_xtal, };
-static const char *cpu_sels[] __initconst = { cpu_pll, cpu_xtal, };
-static const char *emi_sels[] __initconst = { emi_pll, emi_xtal, };
-static const char *ptp_sels[] __initconst = { ref_xtal, pll0, };
+static const char *sel_cpu[]  __initdata = { ref_cpu, ref_xtal, };
+static const char *sel_io0[]  __initdata = { ref_io0, ref_xtal, };
+static const char *sel_io1[]  __initdata = { ref_io1, ref_xtal, };
+static const char *sel_pix[]  __initdata = { ref_pix, ref_xtal, };
+static const char *sel_gpmi[] __initdata = { ref_gpmi, ref_xtal, };
+static const char *sel_pll0[] __initdata = { pll0, ref_xtal, };
+static const char *cpu_sels[] __initdata = { cpu_pll, cpu_xtal, };
+static const char *emi_sels[] __initdata = { emi_pll, emi_xtal, };
+static const char *ptp_sels[] __initdata = { ref_xtal, pll0, };
 
 enum imx28_clk {
ref_xtal, pll0, pll1, pll2, ref_cpu, ref_emi, ref_io0, ref_io1,
diff --git a/drivers/clk/rockchip/clk.h b/drivers/clk/rockchip/clk.h
index 887cbdeca2aa..74fbb9c4b6de 100644
--- a/drivers/clk/rockchip/clk.h
+++ b/drivers/clk/rockchip/clk.h
@@ -120,7 +120,7 @@ struct clk *rockchip_clk_register_pll(enum 
rockchip_pll_type pll_type,
struct rockchip_pll_rate_table *rate_table,
spinlock_t *lock);
 
-#define PNAME

Re: [PATCH] clk: don't use __initconst for non-const arrays

2014-09-11 Thread Uwe Kleine-König
Hello,

On Thu, Sep 11, 2014 at 11:04:31PM +0200, Uwe Kleine-König wrote:
  /* Mux parent lists. */
 -static const char *fin_pll_p[] __initconst = {
 +static const char *fin_pll_p[] __initdata = {
   xxti,
   xusbxti
  };
As discussed with Tomasz on irc: The sad thing here is that for this
array only 8 bytes are freed when .init.rodata is thrown away (that is
two pointers). The actual data---5 + 8 bytes + maybe aligning---isn't
freed though.

We wondered if there is a nice and easy way to throw away the
characters, too.

The only way I currently see is:

const char xxti[] __initconst = xxti;
...

static const char *fin_pll_p[] __initdata = {
xxti,
...
};

but this definitively doesn't qualify as nice and easy. Is there an
alternative?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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] ARM: exynos: remove unused mach/memory.h

2014-07-23 Thread Uwe Kleine-König
Hello,

On Tue, Jul 22, 2014 at 09:14:33AM -0700, Olof Johansson wrote:
  Patch 2 (v2!)
 
  ARM: remove remaining definitions of PLAT_PHYS_OFFSET from 
  mach/memory.h
 
  touches several arch/arm/mach-*/include/mach/memory.h and
  arch/arm/Kconfig. armsoc? Russell?
 
 This can go through either, but Russell has already reviewed it once
 so send it to his patch tracker.
 
  Patch 3 fixes a warning regarding nommu and touches the Kconfig entry
  for Integrator and Renesas (non-multiplatform). armsoc?
 
 Don't know without seeing the patch. What's the patch subject so I can find 
 it?
I talked to Olof on irc. I sent patches 2 and 3 to the patch tracker as

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8112/1

and

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8113/1

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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/3] ARM: exynos: remove unused mach/memory.h

2014-07-02 Thread Uwe Kleine-König
ARCH_EXYNOS doesn't select NEED_MACH_MEMORY_H, so asm/memory.h doesn't
include mach/memory.h and so this file is not used and can go away.

Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-samsung-soc@vger.kernel.org
---
 arch/arm/mach-exynos/include/mach/memory.h | 27 ---
 1 file changed, 27 deletions(-)
 delete mode 100644 arch/arm/mach-exynos/include/mach/memory.h

diff --git a/arch/arm/mach-exynos/include/mach/memory.h 
b/arch/arm/mach-exynos/include/mach/memory.h
deleted file mode 100644
index 2a4cdb7cb326..
--- a/arch/arm/mach-exynos/include/mach/memory.h
+++ /dev/null
@@ -1,27 +0,0 @@
-/* linux/arch/arm/mach-exynos4/include/mach/memory.h
- *
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * EXYNOS4 - Memory definitions
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#ifndef __ASM_ARCH_MEMORY_H
-#define __ASM_ARCH_MEMORY_H __FILE__
-
-#define PLAT_PHYS_OFFSET   UL(0x4000)
-
-#ifndef CONFIG_ARM_LPAE
-/* Maximum of 256MiB in one bank */
-#define MAX_PHYSMEM_BITS   32
-#define SECTION_SIZE_BITS  28
-#else
-#define MAX_PHYSMEM_BITS   36
-#define SECTION_SIZE_BITS  31
-#endif
-
-#endif /* __ASM_ARCH_MEMORY_H */
-- 
2.0.0

--
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 4/8] input: Remove OOM message after input_allocate_device

2013-10-24 Thread Uwe Kleine-König
Hello Joe,

On Wed, Oct 23, 2013 at 12:14:50PM -0700, Joe Perches wrote:
 Emitting an OOM message isn't necessary after input_allocate_device
 as there's a generic OOM and a dump_stack already done.
 
 [...]
 Signed-off-by: Joe Perches j...@perches.com
 diff --git a/drivers/input/joystick/as5011.c b/drivers/input/joystick/as5011.c
 index 005d852..3b9c709 100644
 --- a/drivers/input/joystick/as5011.c
 +++ b/drivers/input/joystick/as5011.c
 @@ -254,8 +254,6 @@ static int as5011_probe(struct i2c_client *client,
   as5011 = kmalloc(sizeof(struct as5011_device), GFP_KERNEL);
   input_dev = input_allocate_device();
   if (!as5011 || !input_dev) {
 - dev_err(client-dev,
 - Can't allocate memory for device structure\n);
Don't know if that can happen, but if as5011 is NULL but input_dev isn't
the message would still be sensible, wouldn't it? There are several more
that suffer the same problem.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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 4/8] input: Remove OOM message after input_allocate_device

2013-10-24 Thread Uwe Kleine-König
On Thu, Oct 24, 2013 at 11:43:38AM -0700, Joe Perches wrote:
 On Thu, 2013-10-24 at 20:26 +0200, Uwe Kleine-König wrote:
  Hello Joe,
  
  On Wed, Oct 23, 2013 at 12:14:50PM -0700, Joe Perches wrote:
   Emitting an OOM message isn't necessary after input_allocate_device
   as there's a generic OOM and a dump_stack already done.
   
   [...]
   Signed-off-by: Joe Perches j...@perches.com
   diff --git a/drivers/input/joystick/as5011.c 
   b/drivers/input/joystick/as5011.c
   index 005d852..3b9c709 100644
   --- a/drivers/input/joystick/as5011.c
   +++ b/drivers/input/joystick/as5011.c
   @@ -254,8 +254,6 @@ static int as5011_probe(struct i2c_client *client,
 as5011 = kmalloc(sizeof(struct as5011_device), GFP_KERNEL);
 input_dev = input_allocate_device();
 if (!as5011 || !input_dev) {
   - dev_err(client-dev,
   - Can't allocate memory for device structure\n);
  Don't know if that can happen, but if as5011 is NULL but input_dev isn't
  the message would still be sensible, wouldn't it? There are several more
  that suffer the same problem.
 
 Any k.alloc without __GFP_NOWARN does a generic OOM message
 and a dump_stack() so there could already be 2 messages anyway.
Then mention that in the commit log if you still want this patch?!

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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 4/8] input: Remove OOM message after input_allocate_device

2013-10-24 Thread Uwe Kleine-König
On Thu, Oct 24, 2013 at 11:48:48AM -0700, Joe Perches wrote:
 On Thu, 2013-10-24 at 20:46 +0200, Uwe Kleine-König wrote:
  On Thu, Oct 24, 2013 at 11:43:38AM -0700, Joe Perches wrote:
 []
   Any k.alloc without __GFP_NOWARN does a generic OOM message
   and a dump_stack() so there could already be 2 messages anyway.
  Then mention that in the commit log if you still want this patch?!
 
 How do you think this commit message should be changed:
 
 Emitting an OOM message isn't necessary after input_allocate_device
 as there's a generic OOM and a dump_stack already done.
after input_allocate_device and/or k.alloc ...

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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] i2c: s3c2410: Add SMBus emulation for block read

2013-04-09 Thread Uwe Kleine-König
Hello,

On Tue, Mar 26, 2013 at 07:59:56PM +0530, Prasanna Kumar wrote:
 diff --git a/drivers/i2c/busses/i2c-s3c2410.c 
 b/drivers/i2c/busses/i2c-s3c2410.c
 index 17c5c37..e4ab9ea 100644
 --- a/drivers/i2c/busses/i2c-s3c2410.c
 +++ b/drivers/i2c/busses/i2c-s3c2410.c
 @@ -309,6 +309,12 @@ static inline int is_lastmsg(struct s3c24xx_i2c *i2c)
  
  static inline int is_msglast(struct s3c24xx_i2c *i2c)
  {
 + /* msg-len is always 1 for the first byte of smbus block read.
 +  * Actual length will be read from slave. More bytes will be
 +  * read according to the length then. */
 + if (i2c-msg-flags  I2C_M_RECV_LEN  i2c-msg-len == 1)
 + return 0;
 +
   return i2c-msg_ptr == i2c-msg-len-1;
  }
  
 @@ -448,6 +454,9 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c, 
 unsigned long iicstat)
   byte = readb(i2c-regs + S3C2410_IICDS);
   i2c-msg-buf[i2c-msg_ptr++] = byte;
  
 + /* Add actual length to read for smbus block read */
 + if (i2c-msg-flags  I2C_M_RECV_LEN  i2c-msg-len == 1)
 + i2c-msg-len += byte;
   prepare_read:
   if (is_msglast(i2c)) {
I don't know if that can happen, but if the block has length 0 (that is,
only consists of a single byte that is read as 0) the is_msglast() test
returns 0 which might be wrong. Maybe even if it cannot regularily
happen handle it in a sane way?

Also I wonder if error checking for byte  I2C_SMBUS_BLOCK_MAX would be
needed to prevent a buffer overrun?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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] clk: let mxs specific clk-div clock type be a generic clock type

2013-03-18 Thread Uwe Kleine-König
Hello,

On Mon, Mar 18, 2013 at 03:48:24PM +0530, Thomas Abraham wrote:
 On 18 March 2013 14:12, Shawn Guo shawn@linaro.org wrote:
  On Sat, Mar 16, 2013 at 06:20:01PM +0530, Thomas Abraham wrote:
  The mxs platform specific clk-div clock is an extended version of the
  basic integer divider clock type that supports checking the stability
  status of the divider clock output. This type of clock is found on
  some of the Samsung platforms as well. So let the mxs specfic clk-div
  clock type be a generic clock type that all platforms can utilize.
 
  Cc: Shawn Guo shawn@linaro.org
  Cc: Mike Turquette mturque...@linaro.org
  Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
  ---
   drivers/clk/Makefile |1 +
   drivers/clk/clk-divider-status.c |  119 
  ++
   drivers/clk/mxs/Makefile |2 +-
   drivers/clk/mxs/clk-div.c|  110 
  ---
   drivers/clk/mxs/clk.h|   12 +++-
   include/linux/clk-provider.h |   21 +++
   6 files changed, 151 insertions(+), 114 deletions(-)
   create mode 100644 drivers/clk/clk-divider-status.c
   delete mode 100644 drivers/clk/mxs/clk-div.c
 
  From my quick testing, it seems working for mxs platform.  But it's hard
  to review the changes.  Making it two steps might be helpful for
  reviewer:
 
  1) git mv drivers/clk/mxs/clk-div.c drivers/clk/clk-divider-status.c
  2) make changes on drivers/clk/clk-divider-status.c
 
 Thanks Shawn for your comments. I will split this patch as you
 suggested and post again.
I didn't try to look at your patch, but maybe format-patch -M is enough
to make the patch easier to parse (for humans).

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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


$(make uImage) is stupid [Was: Re: Early kernel hang with big DTB appended]

2013-01-14 Thread Uwe Kleine-König
Hello,

unrelated to the original problem ...

On Fri, Jan 04, 2013 at 11:18:56AM +0100, Tomasz Figa wrote:
 We are using uImages built with same parameters as those used in simple 
 'make uImage', just with a DTB appended to zImage before running mkimage 
 on it.
note that the parameters used for $(make uImage) are not optimal, only
safe. They use (letting the MMU aside) the link address of the final
image as load address. That means as U-Boot probably didn't choose the
right address when reading the image it has to move it to the link
address and then jumps into it. Then the decompressor notices that the
compressed image is located where the decompressed image should go to
and so has to move the image again.

So you could save quite some time during boot if you'd teach U-Boot that
it can just use the image where it was loaded to.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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 03/17] ARM: mark const init data with __initconst instead of __initdata

2012-03-30 Thread Uwe Kleine-König
Hello Shawn,

On Fri, Mar 30, 2012 at 02:11:36PM +0800, Shawn Guo wrote:
 On Thu, Mar 29, 2012 at 11:12:20PM +0200, Uwe Kleine-König wrote:
 ...
  diff --git a/arch/arm/mach-imx/imx51-dt.c b/arch/arm/mach-imx/imx51-dt.c
  index 5cca573..7e00748 100644
  --- a/arch/arm/mach-imx/imx51-dt.c
  +++ b/arch/arm/mach-imx/imx51-dt.c
  @@ -102,7 +102,7 @@ static struct sys_timer imx51_timer = {
  .init = imx51_timer_init,
   };
   
  -static const char *imx51_dt_board_compat[] __initdata = {
  +static const char *imx51_dt_board_compat[] __initconst = {
  fsl,imx51-babbage,
  fsl,imx51,
  NULL
 
   CC  arch/arm/mach-imx/imx51-dt.o
 arch/arm/mach-imx/imx51-dt.c:105:20: error: imx51_dt_board_compat causes a 
 section type conflict
 make[2]: *** [arch/arm/mach-imx/imx51-dt.o] Error 1
 
 I do not understand why though.
that's because the strings are constant, but the array is not. The fix
is:

-static const char *imx51_dt_board_compat[] __initconst = {
+static const char *const imx51_dt_board_compat[] __initconst = {

or keeping __initdata.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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 02/15] ARM: mark const init data with __initconst instead of __initdata

2012-03-30 Thread Uwe Kleine-König
As long as there is no other non-const variable marked __initdata in the
same compilation unit it doesn't hurt. If there were one however
compilation would fail with

error: $variablename causes a section type conflict

because a section containing const variables is marked read only and so
cannot contain non-const variables.

Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
Cc: Andrew Victor li...@maxim.org.za
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Shawn Guo shawn@linaro.org
Cc: Lennert Buytenhek ker...@wantstofly.org
Cc: Nicolas Pitre n...@fluxnic.net
Cc: Eric Miao eric.y.m...@gmail.com
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: David Brown dav...@codeaurora.org
Cc: Daniel Walker dwal...@fifo99.com
Cc: Bryan Huntsman bry...@codeaurora.org
Cc: Tony Lindgren t...@atomide.com
Cc: Barry Song baohua.s...@csr.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Lucas De Marchi lucas.demar...@profusion.mobi
Cc: linux-arm-ker...@lists.infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
---
changes since (implicit) v1:
 - drop changes to several files that were wrong:
   - arch/arm/mach-at91/board-dt.c
   - arch/arm/mach-exynos/*
   - arch/arm/mach-imx/*
   - arch/arm/mach-mmp/mmp-dt.c
   - arch/arm/mach-msm/board-msm8x60.c
   - arch/arm/mach-omap2/board-generic.c
   - arch/arm/mach-omap2/voltagedomains{3x,44}xx_data.c
   - arch/arm/mach-prima2
 - fix position of __initconst
   - arch/arm/mach-kirkwood/addr-map.c
   - arch/arm/mach-orion5x/addr-map.c

 arch/arm/mach-at91/clock.c  |2 +-
 arch/arm/mach-davinci/board-tnetv107x-evm.c |6 ++--
 arch/arm/mach-davinci/da830.c   |   48 +--
 arch/arm/mach-davinci/da850.c   |6 ++--
 arch/arm/mach-dove/addr-map.c   |2 +-
 arch/arm/mach-kirkwood/addr-map.c   |2 +-
 arch/arm/mach-msm/board-qsd8x50.c   |4 +--
 arch/arm/mach-omap2/display.c   |6 ++--
 arch/arm/mach-orion5x/addr-map.c|2 +-
 9 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
index a0f4d74..e4a255d 100644
--- a/arch/arm/mach-at91/clock.c
+++ b/arch/arm/mach-at91/clock.c
@@ -613,7 +613,7 @@ fail:
return 0;
 }
 
-static struct clk *const standard_pmc_clocks[] __initdata = {
+static struct clk *const standard_pmc_clocks[] __initconst = {
/* four primary clocks */
clk32k,
main_clk,
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c 
b/arch/arm/mach-davinci/board-tnetv107x-evm.c
index 5f14e30..645a587 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -88,7 +88,7 @@ static struct davinci_mmc_config mmc_config = {
.version= MMC_CTLR_VERSION_1,
 };
 
-static const short sdio1_pins[] __initdata = {
+static const short sdio1_pins[] __initconst = {
TNETV107X_SDIO1_CLK_1,  TNETV107X_SDIO1_CMD_1,
TNETV107X_SDIO1_DATA0_1,TNETV107X_SDIO1_DATA1_1,
TNETV107X_SDIO1_DATA2_1,TNETV107X_SDIO1_DATA3_1,
@@ -96,12 +96,12 @@ static const short sdio1_pins[] __initdata = {
-1
 };
 
-static const short uart1_pins[] __initdata = {
+static const short uart1_pins[] __initconst = {
TNETV107X_UART1_RD, TNETV107X_UART1_TD,
-1
 };
 
-static const short ssp_pins[] __initdata = {
+static const short ssp_pins[] __initconst = {
TNETV107X_SSP0_0, TNETV107X_SSP0_1, TNETV107X_SSP0_2,
TNETV107X_SSP1_0, TNETV107X_SSP1_1, TNETV107X_SSP1_2,
TNETV107X_SSP1_3, -1
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index deee5c2..510648e 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -838,7 +838,7 @@ static const struct mux_config da830_pins[] = {
 #endif
 };
 
-const short da830_emif25_pins[] __initdata = {
+const short da830_emif25_pins[] __initconst = {
DA830_EMA_D_0, DA830_EMA_D_1, DA830_EMA_D_2, DA830_EMA_D_3,
DA830_EMA_D_4, DA830_EMA_D_5, DA830_EMA_D_6, DA830_EMA_D_7,
DA830_EMA_D_8, DA830_EMA_D_9, DA830_EMA_D_10, DA830_EMA_D_11,
@@ -853,19 +853,19 @@ const short da830_emif25_pins[] __initdata = {
-1
 };
 
-const short da830_spi0_pins[] __initdata = {
+const short da830_spi0_pins[] __initconst = {
DA830_SPI0_SOMI_0, DA830_SPI0_SIMO_0, DA830_SPI0_CLK, DA830_NSPI0_ENA,
DA830_NSPI0_SCS_0,
-1
 };
 
-const short da830_spi1_pins[] __initdata = {
+const short da830_spi1_pins[] __initconst = {
DA830_SPI1_SOMI_0, DA830_SPI1_SIMO_0

[PATCH 03/17] ARM: mark const init data with __initconst instead of __initdata

2012-03-29 Thread Uwe Kleine-König
As long as there is no other non-const variable marked __initdata in the
same compilation unit it doesn't hurt. If there were one however
compilation would fail with

error: $variablename causes a section type conflict

because a section containing const variables is marked read only and so
cannot contain non-const variables.

Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
Cc: Andrew Victor li...@maxim.org.za
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Shawn Guo shawn@linaro.org
Cc: Lennert Buytenhek ker...@wantstofly.org
Cc: Nicolas Pitre n...@fluxnic.net
Cc: Eric Miao eric.y.m...@gmail.com
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: David Brown dav...@codeaurora.org
Cc: Daniel Walker dwal...@fifo99.com
Cc: Bryan Huntsman bry...@codeaurora.org
Cc: Tony Lindgren t...@atomide.com
Cc: Barry Song baohua.s...@csr.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Lucas De Marchi lucas.demar...@profusion.mobi
Cc: linux-arm-ker...@lists.infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
---
 arch/arm/mach-at91/board-dt.c |2 +-
 arch/arm/mach-at91/clock.c|2 +-
 arch/arm/mach-davinci/board-tnetv107x-evm.c   |6 ++--
 arch/arm/mach-davinci/da830.c |   48 
 arch/arm/mach-davinci/da850.c |6 ++--
 arch/arm/mach-dove/addr-map.c |2 +-
 arch/arm/mach-exynos/mach-exynos4-dt.c|2 +-
 arch/arm/mach-exynos/mach-exynos5-dt.c|2 +-
 arch/arm/mach-imx/imx27-dt.c  |2 +-
 arch/arm/mach-imx/imx51-dt.c  |2 +-
 arch/arm/mach-imx/imx53-dt.c  |2 +-
 arch/arm/mach-imx/mach-imx6q.c|2 +-
 arch/arm/mach-kirkwood/addr-map.c |2 +-
 arch/arm/mach-mmp/mmp-dt.c|2 +-
 arch/arm/mach-msm/board-msm8x60.c |2 +-
 arch/arm/mach-msm/board-qsd8x50.c |4 +-
 arch/arm/mach-omap2/board-generic.c   |8 ++--
 arch/arm/mach-omap2/display.c |6 ++--
 arch/arm/mach-omap2/voltagedomains3xxx_data.c |2 +-
 arch/arm/mach-omap2/voltagedomains44xx_data.c |2 +-
 arch/arm/mach-orion5x/addr-map.c  |2 +-
 arch/arm/mach-prima2/prima2.c |2 +-
 22 files changed, 55 insertions(+), 55 deletions(-)

diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
index c18d4d3..1c48ea2 100644
--- a/arch/arm/mach-at91/board-dt.c
+++ b/arch/arm/mach-at91/board-dt.c
@@ -48,7 +48,7 @@ static void __init at91_dt_device_init(void)
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-static const char *at91_dt_board_compat[] __initdata = {
+static const char *at91_dt_board_compat[] __initconst = {
atmel,at91sam9m10g45ek,
atmel,at91sam9x5ek,
calao,usb-a9g20,
diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
index a0f4d74..e4a255d 100644
--- a/arch/arm/mach-at91/clock.c
+++ b/arch/arm/mach-at91/clock.c
@@ -613,7 +613,7 @@ fail:
return 0;
 }
 
-static struct clk *const standard_pmc_clocks[] __initdata = {
+static struct clk *const standard_pmc_clocks[] __initconst = {
/* four primary clocks */
clk32k,
main_clk,
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c 
b/arch/arm/mach-davinci/board-tnetv107x-evm.c
index 5f14e30..645a587 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -88,7 +88,7 @@ static struct davinci_mmc_config mmc_config = {
.version= MMC_CTLR_VERSION_1,
 };
 
-static const short sdio1_pins[] __initdata = {
+static const short sdio1_pins[] __initconst = {
TNETV107X_SDIO1_CLK_1,  TNETV107X_SDIO1_CMD_1,
TNETV107X_SDIO1_DATA0_1,TNETV107X_SDIO1_DATA1_1,
TNETV107X_SDIO1_DATA2_1,TNETV107X_SDIO1_DATA3_1,
@@ -96,12 +96,12 @@ static const short sdio1_pins[] __initdata = {
-1
 };
 
-static const short uart1_pins[] __initdata = {
+static const short uart1_pins[] __initconst = {
TNETV107X_UART1_RD, TNETV107X_UART1_TD,
-1
 };
 
-static const short ssp_pins[] __initdata = {
+static const short ssp_pins[] __initconst = {
TNETV107X_SSP0_0, TNETV107X_SSP0_1, TNETV107X_SSP0_2,
TNETV107X_SSP1_0, TNETV107X_SSP1_1, TNETV107X_SSP1_2,
TNETV107X_SSP1_3, -1
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index deee5c2..510648e 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -838,7 +838,7 @@ static

Re: [PATCH] mmc: card: modify mmc_getgeo function

2011-09-26 Thread Uwe Kleine-König
Hello,

On Wed, Sep 21, 2011 at 02:52:08PM -0400, Chris Ball wrote:
 Hi,
 
 On Tue, Sep 20 2011, Girish K S wrote:
  In the earlier code the cylinder, sector and head are assigned
  independently. Current patch generates the cylinder number
  with the values of sector and head.
  This patch only makes they cylinder value to be dependent on
  the sector and head.
 
  Signed-off-by: Girish K S girish.shivananja...@linaro.org
  ---
   drivers/mmc/card/block.c |3 ++-
   1 files changed, 2 insertions(+), 1 deletions(-)
 
  diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
  index 1ff5486..bebb13b 100644
  --- a/drivers/mmc/card/block.c
  +++ b/drivers/mmc/card/block.c
  @@ -226,9 +226,10 @@ static int mmc_blk_release(struct gendisk *disk, 
  fmode_t mode)
   static int
   mmc_blk_getgeo(struct block_device *bdev, struct hd_geometry *geo)
   {
  -   geo-cylinders = get_capacity(bdev-bd_disk) / (4 * 16);
  geo-heads = 4;
  geo-sectors = 16;
  +   geo-cylinders = get_capacity(bdev-bd_disk) /
  +   (geo-heads * geo-sectors);
  return 0;
   }
 
 Thanks, pushed to mmc-next for 3.2 with a reworded commit message:
This (i.e. ee9e0e0 (mmc: card: Remove duplicated constants) in next)
makes gcc emit a reference to __aeabi_uldivmod in one of my nightly
builds which isn't defined.

The final linking stage fails with:

  LD  .tmp_vmlinux1
drivers/built-in.o: In function `mmc_blk_getgeo':
clkdev.c:(.text+0xd1528): undefined reference to `__aeabi_uldivmod'
make[2]: *** [.tmp_vmlinux1] Error 1
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2

(I don't know why clkdev.c is referenced here. I'm not using ccache.)

It seems gcc isn't smart enough to notice that it can just use the same
generated code ...

Having said that AFAIK the code used before wasn't ok, too. (I.e. an u64
division that was just noticed to be a shift by luck.)

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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] mmc: card: modify mmc_getgeo function

2011-09-26 Thread Uwe Kleine-König
On Mon, Sep 26, 2011 at 08:41:13AM -0400, Chris Ball wrote:
 Hi,
 
 On Mon, Sep 26 2011, Uwe Kleine-König wrote:
  Thanks, pushed to mmc-next for 3.2 with a reworded commit message:
  This (i.e. ee9e0e0 (mmc: card: Remove duplicated constants) in next)
  makes gcc emit a reference to __aeabi_uldivmod in one of my nightly
  builds which isn't defined.
 
  The final linking stage fails with:
 
LD  .tmp_vmlinux1
  drivers/built-in.o: In function `mmc_blk_getgeo':
  clkdev.c:(.text+0xd1528): undefined reference to `__aeabi_uldivmod'
  make[2]: *** [.tmp_vmlinux1] Error 1
  make[1]: *** [sub-make] Error 2
  make: *** [all] Error 2
 
 Interesting, thanks.  It builds fine here on my (gcc-4.6) ARM toolchains.
 Looking online, I think you're hitting an old gcc-4.3 bug?
Yeah, this is gcc 4.3.2. Is it too old to be supported?

Do you think of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783? Then
no, that is not the problem. The function is actually used:

0028 mmc_blk_getgeo:
  28:   e3a03004mov r3, #4
  2c:   e3a02010mov r2, #16
  30:   e92d4010push{r4, lr}
  34:   e1a04001mov r4, r1
  38:   e5c13000strbr3, [r1]
  3c:   e5c12001strbr2, [r1, #1]
  40:   e590c050ldr ip, [r0, #80]   ; 0x50
  44:   e3a02040mov r2, #64 ; 0x40
  48:   e3a03000mov r3, #0
  4c:   e1cc04d8ldrdr0, [ip, #72]   ; 0x48
  50:   ebfebl  0 __aeabi_uldivmod
  54:   e1c400b2strhr0, [r4, #2]
  58:   e3a0mov r0, #0
  5c:   e8bd8010pop {r4, pc}

I thought that the problem is more:

 The kernel doesn't support 64-bit by 64-bit division at all then?  
Nope.  64-bit by 64-bit divides are grossly inefficient and should be
avoided.

(taken from http://www.spinics.net/lists/arm/msg13532.html)

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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: S3C64XX: Fix section mismatch from cpufreq init

2011-03-16 Thread Uwe Kleine-König
On Thu, Mar 10, 2011 at 02:58:13PM +, Mark Brown wrote:
 The cpufreq init function is referenced from the driver structure and
 we don't appear to have annotations which allow us to mark that it'll
 never be called after system init, causing the linker consistency
 infrastructure to complain. Just remove the __init annotation to avoid
 noise from the build.
 
 Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
 ---
  arch/arm/mach-s3c64xx/cpufreq.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/mach-s3c64xx/cpufreq.c b/arch/arm/mach-s3c64xx/cpufreq.c
 index 74c0e83..4375b97 100644
 --- a/arch/arm/mach-s3c64xx/cpufreq.c
 +++ b/arch/arm/mach-s3c64xx/cpufreq.c
 @@ -181,7 +181,7 @@ static void __init s3c64xx_cpufreq_config_regulator(void)
  }
  #endif
  
 -static int __init s3c64xx_cpufreq_driver_init(struct cpufreq_policy *policy)
 +static int s3c64xx_cpufreq_driver_init(struct cpufreq_policy *policy)
  {
   int ret;
   struct cpufreq_frequency_table *freq;
Actually this is warning is a false positive.  There is a section
mismatch, but it is never a problem because the .init callback is only
called by cpufreq_register_driver. To get rid of the warning the right
fix is to remove the .init callback from struct cpufreq_driver and
change the prototype of cpufreq_register_driver to

int cpufreq_register_driver(struct cpufreq_driver *, int (*)(struct 
cpufreq_policy *))

(that is pass the init callback to cpufreq_register_driver).

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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: S3C64XX: Fix section mismatch from cpufreq init

2011-03-16 Thread Uwe Kleine-König
On Wed, Mar 16, 2011 at 09:49:59AM +, Mark Brown wrote:
 On Wed, Mar 16, 2011 at 09:38:11AM +0100, Uwe Kleine-König wrote:
  On Thu, Mar 10, 2011 at 02:58:13PM +, Mark Brown wrote:
   we don't appear to have annotations which allow us to mark that it'll
   never be called after system init, causing the linker consistency
 
  Actually this is warning is a false positive.  There is a section
  mismatch, but it is never a problem because the .init callback is only
  called by cpufreq_register_driver. To get rid of the warning the right
  fix is to remove the .init callback from struct cpufreq_driver and
  change the prototype of cpufreq_register_driver to
 
 That's what I said above, pretty much.  Ideally we'd have a way of
 annotating the call sites so that the linker infrastructure rather than
 having to faff about splitting the structures like this.
You can mark the driver struct using __ref. But IMHO not saving a
reference to a function only used once is cleaner.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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: [RFC 2/5] ARM: P2V: avoid initializers and assembly using PHYS_OFFSET

2011-02-07 Thread Uwe Kleine-König
Hi Russell,

On Tue, Jan 04, 2011 at 08:22:37PM +, Russell King - ARM Linux wrote:
 As PHYS_OFFSET will be becoming a variable, we can't have it used in
 initializers nor assembly code.  Replace those in generic code with
 a run-time initialization.  Replace those in platform code using the
 individual platform specific PLAT_PHYS_OFFSET.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 ---
  
  arch/arm/mach-mx5/board-cpuimx51.c   |2 +-
  arch/arm/mach-mx5/board-cpuimx51sd.c |2 +-
  arch/arm/mach-mx5/board-mx51_3ds.c   |2 +-
 ...
 diff --git a/arch/arm/mach-mx5/board-cpuimx51.c 
 b/arch/arm/mach-mx5/board-cpuimx51.c
 index 6a9792f..c4c3a9c 100644
 --- a/arch/arm/mach-mx5/board-cpuimx51.c
 +++ b/arch/arm/mach-mx5/board-cpuimx51.c
 @@ -292,7 +292,7 @@ static struct sys_timer mxc_timer = {
  
  MACHINE_START(EUKREA_CPUIMX51, Eukrea CPUIMX51 Module)
   /* Maintainer: Eric B??nard e...@eukrea.com */
 - .boot_params = PHYS_OFFSET + 0x100,
 + .boot_params = PLAT_PHYS_OFFSET + 0x100,
   .map_io = mx51_map_io,
   .init_irq = mx51_init_irq,
   .init_machine = eukrea_cpuimx51_init,
 diff --git a/arch/arm/mach-mx5/board-cpuimx51sd.c 
 b/arch/arm/mach-mx5/board-cpuimx51sd.c
 index 4b3a611..b887381 100644
 --- a/arch/arm/mach-mx5/board-cpuimx51sd.c
 +++ b/arch/arm/mach-mx5/board-cpuimx51sd.c
 @@ -323,7 +323,7 @@ static struct sys_timer mxc_timer = {
  
  MACHINE_START(EUKREA_CPUIMX51SD, Eukrea CPUIMX51SD)
   /* Maintainer: Eric B??nard e...@eukrea.com */
 - .boot_params = PHYS_OFFSET + 0x100,
 + .boot_params = PLAT_PHYS_OFFSET + 0x100,
   .map_io = mx51_map_io,
   .init_irq = mx51_init_irq,
   .init_machine = eukrea_cpuimx51sd_init,
 diff --git a/arch/arm/mach-mx5/board-mx51_3ds.c 
 b/arch/arm/mach-mx5/board-mx51_3ds.c
 index 79ce8dc..10e6ce3 100644
 --- a/arch/arm/mach-mx5/board-mx51_3ds.c
 +++ b/arch/arm/mach-mx5/board-mx51_3ds.c
 @@ -186,7 +186,7 @@ static struct sys_timer mxc_timer = {
  
  MACHINE_START(MX51_3DS, Freescale MX51 3-Stack Board)
   /* Maintainer: Freescale Semiconductor, Inc. */
 - .boot_params = PHYS_OFFSET + 0x100,
 + .boot_params = PLAT_PHYS_OFFSET + 0x100,
   .map_io = mx51_map_io,
   .init_irq = mx51_init_irq,
   .init_machine = mxc_board_init,
nack.  7608d7d2b4a146f560436f5b99b1b93d30049e4e has a better fix.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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: [RFC 2/5] ARM: P2V: avoid initializers and assembly using PHYS_OFFSET

2011-02-07 Thread Uwe Kleine-König
Hello again,

On Mon, Feb 07, 2011 at 05:51:50PM +0100, Uwe Kleine-König wrote:
 nack.  7608d7d2b4a146f560436f5b99b1b93d30049e4e has a better fix.
urgs, this was already pointed out, sorry.

Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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: git pre-commit hook running checkpatch.pl

2010-01-20 Thread Uwe Kleine-König
On Wed, Jan 20, 2010 at 10:01:55AM +, Mark Brown wrote:
 On Wed, Jan 20, 2010 at 02:02:02AM +, Ben Dooks wrote:
 
  I've written a git pre-commit[1] hook which stops any commits happening if
  checkpatch.pl reports problems with the patch. Any comments?
 
  [1] http://www.fluff.org/ben/linux/githooks/pre-commit
 
 Checkpatch does sometimes generate the occasional false positive which
 can be annoying when they trigger.  It can also be a problem when doing
 bugfixes IME - if an existing file has lots of checkpatch issues then a
 fix which maintains the same coding style as the surrounding code can
 trigger checkpatch issues which would if fixed make the code not fit in
 with the rest of the file.  Obviously it'd be desirable to fix the file
 but that's a bit unreasonable for people submitting bug fixes,
 especially when pushing fixes to Linus and stable.
 
 That said, monitoring for checkpatch issues is useful.
Maybe only print the warnings instead of stopping a commit?  I'd not
like me stopping here not only for the reasons pointed out by Mark and
Russell, but also as I frequently do wip-commits that not necessarily
are checkpatch-clean.

Best regards
Uwe

-- 
Pengutronix e.K.  | Uwe Kleine-König|
Industrial Linux Solutions| http://www.pengutronix.de/  |
--
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