Re: [PATCH v3] clk: s3c2410: removed unneeded variable in s3c24xx_clkout_set_parent
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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
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
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
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
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
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
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
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
