Re: [PATCH 0/3 v3] Fix Exynos USB on kernels with USB Gadget support
Hey Kukjin, It's been almost a month since I posted the first iteration of this patchset on the list, with only trivial cosmetic changes and an addition of a similar fix for Arndale Octa boards. Do you feel it needs more review from specific folks before pulling it in or ? Seems a bit of a shame if this would fail to make it for 3.18 (one could even argue the dt patches are 3.17 RC material!) as it fixes USB functionality being broken depending on the kernel configuration used. On Mon, 2014-09-15 at 12:52 +0200, Sjoerd Simons wrote: > When building a kernel with support for both USB host and USB Gadget support > on > the dwc3 controller on the Exynos5 soc will go into USB OTG mode unless > otherwise specified in the dtb, which is unhelpful for boards hooked up to run > as USB host. > > First patch in this set explicitely set the dual-role mode for the dwc3 > controller on Peach pi and Peach pit boards to host mode. Second patch adds > similar updates for Arndale Octa as reported by Andreas Färber. Last patch > enables gadget mode in the default exynos config to more easily catch/trigger > issues like these. > > I suspect the Samsung SMDK5420 DTS might need similar changes, so it would be > great if users of those board could verify this. > > Changes in v2: alphabetically sort the dts entries > Changes in v3: Add DTS updates for arndale octa > > Sjoerd Simons (3): > ARM: dts: exynos: Explicitly set dr_mode on peach-pit and peach-pi > ARM: dts: exynos: Explicitly set dr_mode on arndale-octa > ARM: exynos_defconfig: enable USB gadget support > > arch/arm/boot/dts/exynos5420-arndale-octa.dts | 4 > arch/arm/boot/dts/exynos5420-peach-pit.dts| 8 > arch/arm/boot/dts/exynos5420.dtsi | 4 ++-- > arch/arm/boot/dts/exynos5800-peach-pi.dts | 8 > arch/arm/configs/exynos_defconfig | 1 + > 5 files changed, 23 insertions(+), 2 deletions(-) > smime.p7s Description: S/MIME cryptographic signature
[PATCH 0/2 v2] Add OF match tables for the ChromeOs EC subdevices
[ This is essentially a resend, adding Javiers reviewed-by and fixing some small identation issues in the second patch. Also added Wolfgang and Dimitry in the to, as i missed them last time ] The ChromeOS EC MFD driver registers its sub-devices with both a (platform) name and an OF compatibility string. As a result of this the modalias passed on to user-space will be based on the OF compatibility string. Thus to be able to rely on autoloading in case the subdevices are build as modules they need to export the necessary module aliases based to match the of information. The two patches in these series add the requird of match information to the EC subdevices I guess the first patch should through the i2c tree while the second one would be for the input tree? Sjoerd Simons (2): i2c: cros-ec-tunnel: Add of match table input: cros_ec_keyb: Add of match table drivers/i2c/busses/i2c-cros-ec-tunnel.c | 9 + drivers/input/keyboard/cros_ec_keyb.c | 9 + 2 files changed, 18 insertions(+) -- 2.1.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
[PATCH 2/2] input: cros_ec_keyb: Add of match table
To enable the cros_ec_keyb driver to be auto-loaded when build as
module add an of match table (and export it) to match the modalias
information passed on to userspace as the Cros EC MFD driver registers
the MFD subdevices with an of_compatibility string.
Signed-off-by: Sjoerd Simons
Reviewed-by: Javier Martinez Canillas
---
Changes in v2: Fixed some indentation issues
drivers/input/keyboard/cros_ec_keyb.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 791781a..e1903ec 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -342,10 +342,19 @@ static int cros_ec_keyb_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(cros_ec_keyb_pm_ops, NULL, cros_ec_keyb_resume);
+#ifdef CONFIG_OF
+static const struct of_device_id cros_ec_keyb_of_match[] = {
+ { .compatible = "google,cros-ec-keyb" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, cros_ec_keyb_of_match);
+#endif
+
static struct platform_driver cros_ec_keyb_driver = {
.probe = cros_ec_keyb_probe,
.driver = {
.name = "cros-ec-keyb",
+ .of_match_table = of_match_ptr(cros_ec_keyb_of_match),
.pm = &cros_ec_keyb_pm_ops,
},
};
--
2.1.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
[PATCH 1/2 v2] i2c: cros-ec-tunnel: Add of match table
To enable the cros-ec-tunnel driver to be auto-loaded when build as a
module add an of match table (and export it) to match the modalias
information passed on to userspace as the Cros EC MFD driver registers
the MFD subdevices with an of_compatibility string.
Signed-off-by: Sjoerd Simons
Reviewed-by: Javier Martinez Canillas
---
Changes in v2: none
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 05e033c..0403ec1 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -310,11 +310,20 @@ static int ec_i2c_remove(struct platform_device *dev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id cros_ec_i2c_of_match[] = {
+ { .compatible = "google,cros-ec-i2c-tunnel" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, cros_ec_i2c_of_match);
+#endif
+
static struct platform_driver ec_i2c_tunnel_driver = {
.probe = ec_i2c_probe,
.remove = ec_i2c_remove,
.driver = {
.name = "cros-ec-i2c-tunnel",
+ .of_match_table = of_match_ptr(cros_ec_i2c_of_match),
},
};
--
2.1.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
[PATCH] clk: s5pv210: add missing call to samsung_clk_of_add_provider()
Commit d5e136a21b2028fb1f45143ea7112d5869bfc6c7 ("clk: samsung: Register
clk provider only after registering its all clocks", merged to v3.17-rc1)
modified a way that driver registers registers to core framework. This
change has not been applied to s5pv210 clocks driver, which has been
merged in parallel to that commit. This patch adds a missing call to
samsung_clk_of_add_provider(), so the driver is operational again.
Signed-off-by: Marek Szyprowski
---
Hello!
This is an important fix to v3.17-rcX. Without it support for Samsung
S5PV210 SoCs is not functional.
Mike, could you take it to the fixes branch?
Best regards
Marek Szyprowski, PhD
Samsung R&D Institute Poland
---
drivers/clk/samsung/clk-s5pv210.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/samsung/clk-s5pv210.c
b/drivers/clk/samsung/clk-s5pv210.c
index d270a20..f41b017 100644
--- a/drivers/clk/samsung/clk-s5pv210.c
+++ b/drivers/clk/samsung/clk-s5pv210.c
@@ -828,6 +828,8 @@ static void __init __s5pv210_clk_init(struct device_node
*np,
s5pv210_clk_sleep_init();
+ samsung_clk_of_add_provider(np, ctx);
+
pr_info("%s clocks: mout_apll = %ld, mout_mpll = %ld\n"
"\tmout_epll = %ld, mout_vpll = %ld\n",
is_s5p6442 ? "S5P6442" : "S5PV210",
--
1.9.2
--
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] mfd: syscon: Decouple syscon interface from platform devices
Hi Dong and Xiubo,
On Friday, September 19, 2014, Dong Aisheng wrote,
> On Fri, Sep 19, 2014 at 01:20:18PM +0800, Xiubo Li-B47053 wrote:
> > [...]
> > > >create child: /dcsr@2000/dcsr-atbrepl@3a8000
> > > >create child: /dcsr@2000/dcsr-tsgen-ctrl@3a9000
> > > >create child: /dcsr@2000/dcsr-tsgen-read@3aa000
> > > >create child: /regulators/regulator@0
> > > >...
> > > >
> > > > As default the Linux will create all the platform device for each
> > > > DT node,
> > > which
> > > > Can be found from "drivers/of/platform.c".
> > > >
> > > > So we can get the pdev node using the specified DT node, and feel
> > > > safe to
> > > use
> > > > it as Pankaj's patch does.
> > > >
> > >
> > > I mean before the devices are populated from device tree.
> > > For example, we usually call of_platform_populate in .init_machine.
> > > Before it, we may not be able to get it's device, isn't it?
> > >
> >
> > Yes, right.
> >
> > For this case, we'd better create the pdev or dev manually for the
> > first time We use it, right ?
>
> Yes, that's my understanding.
>
Thanks for all your inputs.
First let me clarify that the main purpose of this patch, we introduced this
patch mainly because
if some HW IP is having secondary compatibility as "syscon", syscon driver
was getting probed
and since there can be only on platform_device corresponding to one
device_node, actual driver
corresponding to that HW IP was not getting probed. So we wanted to decouple
syscon from platform
device, and any such driver should be able to become syscon provider. Please
see discussion here [1].
[1]: https://lkml.org/lkml/2014/6/17/331
But while doing so eventually this patch was also able to cover the feature
of early availability of syscon
lookup APIs.
As both of you pointed out that if we use "of_find_device_by_node" and it
won't work for early users
of syscon. I also agree with that, but it just skipped from my mind while
suggesting that approach.
I reconsidered again and made following changes and tested it. Now I am able
to use syscon_lookup_by_x
APIs, very early (before dt_machine_init) as well as after
of_platform_populate. So please review and if
it is acceptable I will post next version of this patch.
Basic idea is, check for device_node pointer in of_syscon_register, if
device corresponding to that device_node
is already populated and available use "of_find_device_by_node" else create
a dummy platform device and then
use it.
--
static struct syscon *of_syscon_register(struct device_node *np)
{
+ struct platform_device *pdev = NULL;
struct syscon *syscon;
struct regmap *regmap;
void __iomem *base;
+ struct platform_device dummy_pdev = {
+ .name = "dummy-syscon",
+ .id= -1,
+ };
+
if (!of_device_is_compatible(np, "syscon"))
return ERR_PTR(-EINVAL);
@@ -141,8 +149,22 @@ static struct syscon *of_syscon_register(struct
device_node *np)
base = of_iomap(np, 0);
if (!base)
return ERR_PTR(-ENOMEM);
+
+ if (!of_device_is_available(np) ||
+ of_node_test_and_set_flag(np, OF_POPULATED)) {
+ /* if device is already populated and avaiable then use it
*/
+ pdev = of_find_device_by_node(np);
+ if (!(&pdev->dev))
+ return ERR_PTR(-ENODEV);
+
+ regmap = regmap_init_mmio(&pdev->dev, base,
&syscon_regmap_config);
+ } else {
+ /* for early users let's create dummy syscon device and use
it */
+ device_initialize(&dummy_pdev.dev);
+ dummy_pdev.dev.of_node = np;
+ regmap = regmap_init_mmio(&dummy_pdev.dev, base,
&syscon_regmap_config);
+ }
- regmap = regmap_init_mmio(NULL, base, &syscon_regmap_config);
if (IS_ERR(regmap)) {
pr_err("regmap init failed\n");
return ERR_CAST(regmap);
--
Thanks,
Pankaj Dubey
> Regards
> Dong Aisheng
>
> >
> > Thanks,
> >
> > BRs
> > Xiubo
> >
> >
> > > Regards
> > > Dong Aisheng
> > >
> > > > And also we must make sure that the 'syscon' DT nodes has the
> > > > compatible
> > > prop.
> > > >
> > > > Thanks,
> > > >
> > > > BRs
> > > > Xiubo
> > > >
> > > >
> > > > > Regards
> > > > > Dong Aisheng
> > > > >
> > > > > >
> > > > > > static struct syscon *of_syscon_register(struct device_node
> > > > > > *np) {
> > > > > > + struct platform_device *pdev;
> > > > > > struct syscon *syscon;
> > > > > > struct regmap *regmap;
> > > > > > void __iomem *base;
> > > > > > @@ -142,7 +144,11 @@ static struct syscon
> > > > > > *of_syscon_register(struct device_node *np)
> > > > > > if (!base)
> > > > > > return ERR_PTR(-ENOMEM);
> > > > > >
> > > > > > - regmap = regmap_init_mmio(NULL, base,
&syscon_regmap_config);
> > > > > > + pdev = of_find_device_by_node(np);
> > > > > >
Re: [PATCH v4 4/7] ARM: l2c: Add support for overriding prefetch settings
On 26/08/2014 at 16:17:57 +0200, Tomasz Figa wrote :
> Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch
> settings configured in registers leading to crashes if L2C is enabled
> without overriding them. This patch introduces bindings to enable
> prefetch settings to be specified from DT and necessary support in the
> driver.
>
> Signed-off-by: Tomasz Figa
Tested-by: Alexandre Belloni
It is working and useful on Atmel's sama5d4 were the bootloader is not
configuring the L2C prefetch. However, I'm wondering whether we should
add support for setting L310_PREFETCH_CTRL_DATA_PREFETCH and
L310_PREFETCH_CTRL_INSTR_PREFETCH. I'm currently doing it by using
".l2c_aux_val= L310_AUX_CTRL_DATA_PREFETCH |
L310_AUX_CTRL_INSTR_PREFETCH" (those are the same bits) but this has the
disadvantage of displaying the "L2C: platform modifies aux control
register:" twice.
> + if (!of_property_read_u32(np, "arm,prefetch-offset", &val)) {
> + prefetch &= ~L310_PREFETCH_CTRL_OFFSET_MASK;
> + prefetch |= val & L310_PREFETCH_CTRL_OFFSET_MASK;
> + }
> +
While you use val directly here, later, while printing the offset, val +
1 is used. Maybe it would be better to have the same number in both
places, else you end up with having "arm,prefetch-offset = <1>" in your
DT and the kernel printing "L2C-310 ID prefetch enabled, offset 2
lines".
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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 v10 0/6] Add Maxim 77802 RTC support
Hello Andrew, This series add support for the Real Time clock present in the Maxim 77802 Power Managment IC. The version number is quite high because it previously was part of a bigger series [0] that aimed to add support for all the devices in the max77802 PMIC. But now that the max77802 dependencies were already merged for 3.17, the series were split but I kept the version numbering. While working on the max77802 rtc support a lot of feedback was given and the issues pointed out also apply to a driver for a similar PMIC RTC (max77686). So patches 01/06 to 05/06 in the series are cleanups for the max77686 driver and patch 06/06 adds the support for the max77802 RTC. This version address the issues pointed out on the previous version [1] and changelog are present on each patch when is applicable. The series were tested on an Exynos5250 Snow (max77686) and Exynos5420 Peach Pit (max77802) machines and applies cleanly to both 3.17-rc1 and today's linux-next (20140919). NOTE: The patches from the previous version [1] were already present in the -mm tree [2] so I didn't know if I should had sent this as a delta or as a new revision. I decided to do the later but please let me know if you expected the former. Doug Anderson (1): rtc: max77686: Allow the max77686 rtc to wakeup the system Javier Martinez Canillas (5): rtc: max77686: Remove dead code for SMPL and WTSR. rtc: max77686: Fail to probe if no RTC regmap irqchip is set rtc: max77686: Remove unneded info log rtc: max77686: Use ffs() to calculate tm_wday rtc: Add driver for Maxim 77802 PMIC Real-Time-Clock drivers/rtc/Kconfig| 10 + drivers/rtc/Makefile | 1 + drivers/rtc/rtc-max77686.c | 139 +++-- drivers/rtc/rtc-max77802.c | 501 + 4 files changed, 542 insertions(+), 109 deletions(-) create mode 100644 drivers/rtc/rtc-max77802.c [0]: http://lwn.net/Articles/605350/ [1]: https://lkml.org/lkml/2014/9/12/87 [2]: http://ozlabs.org/~akpm/mmots/series -- 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 v10 6/6] rtc: Add driver for Maxim 77802 PMIC Real-Time-Clock
The MAX7802 PMIC has a Real-Time-Clock (RTC) with two alarms.
This patch adds support for the RTC and is based on a driver
added by Simon Glass to the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Krzysztof Kozlowski
---
Changes since v9:
- Use ffs() to calculate tm_wday instead of a custom function.
Suggested by Andrew Morton.
Changes since v8: None
Changes since v7: None
Changes since v6:
- Remove unused code for SMPL and WTSR. Suggested by Krzysztof Kozlowski.
- Don't spam the kernel log with unnecessarily info and just print for debug.
Suggested by Krzysztof Kozlowski.
- Use ARRAY_SIZE() instead of constant value. Suggested by Krzysztof Kozlowski.
- Remove duplicated register setup. Suggested by Krzysztof Kozlowski.
- Don't free/unregister managed allocated resources.
Suggested by Krzysztof Kozlowski.
drivers/rtc/Kconfig| 10 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-max77802.c | 501 +
3 files changed, 512 insertions(+)
create mode 100644 drivers/rtc/rtc-max77802.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index fae9464..241b8be 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -288,6 +288,16 @@ config RTC_DRV_MAX77686
This driver can also be built as a module. If so, the module
will be called rtc-max77686.
+config RTC_DRV_MAX77802
+ tristate "Maxim 77802 RTC"
+ depends on MFD_MAX77686
+ help
+ If you say yes here you will get support for the
+ RTC of Maxim MAX77802 PMIC.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-max77802.
+
config RTC_DRV_RS5C372
tristate "Ricoh R2025S/D, RS5C372A/B, RV5C386, RV5C387A"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 56f061c..d55ebe2 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_RTC_DRV_MAX8998) += rtc-max8998.o
obj-$(CONFIG_RTC_DRV_MAX8997) += rtc-max8997.o
obj-$(CONFIG_RTC_DRV_MAX6902) += rtc-max6902.o
obj-$(CONFIG_RTC_DRV_MAX77686) += rtc-max77686.o
+obj-$(CONFIG_RTC_DRV_MAX77802) += rtc-max77802.o
obj-$(CONFIG_RTC_DRV_MC13XXX) += rtc-mc13xxx.o
obj-$(CONFIG_RTC_DRV_MCP795) += rtc-mcp795.o
obj-$(CONFIG_RTC_DRV_MSM6242) += rtc-msm6242.o
diff --git a/drivers/rtc/rtc-max77802.c b/drivers/rtc/rtc-max77802.c
new file mode 100644
index 000..3a00ec2
--- /dev/null
+++ b/drivers/rtc/rtc-max77802.c
@@ -0,0 +1,501 @@
+/*
+ * RTC driver for Maxim MAX77802
+ *
+ * Copyright (C) 2013 Google, Inc
+ *
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ *
+ * based on rtc-max8997.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* RTC Control Register */
+#define BCD_EN_SHIFT 0
+#define BCD_EN_MASK(1 << BCD_EN_SHIFT)
+#define MODEL24_SHIFT 1
+#define MODEL24_MASK (1 << MODEL24_SHIFT)
+/* RTC Update Register1 */
+#define RTC_UDR_SHIFT 0
+#define RTC_UDR_MASK (1 << RTC_UDR_SHIFT)
+#define RTC_RBUDR_SHIFT4
+#define RTC_RBUDR_MASK (1 << RTC_RBUDR_SHIFT)
+/* RTC Hour register */
+#define HOUR_PM_SHIFT 6
+#define HOUR_PM_MASK (1 << HOUR_PM_SHIFT)
+/* RTC Alarm Enable */
+#define ALARM_ENABLE_SHIFT 7
+#define ALARM_ENABLE_MASK (1 << ALARM_ENABLE_SHIFT)
+
+/* For the RTCAE1 register, we write this value to enable the alarm */
+#define ALARM_ENABLE_VALUE 0x77
+
+#define MAX77802_RTC_UPDATE_DELAY_US 200
+
+enum {
+ RTC_SEC = 0,
+ RTC_MIN,
+ RTC_HOUR,
+ RTC_WEEKDAY,
+ RTC_MONTH,
+ RTC_YEAR,
+ RTC_DATE,
+ RTC_NR_TIME
+};
+
+struct max77802_rtc_info {
+ struct device *dev;
+ struct max77686_dev *max77802;
+ struct i2c_client *rtc;
+ struct rtc_device *rtc_dev;
+ struct mutexlock;
+
+ struct regmap *regmap;
+
+ int virq;
+ int rtc_24hr_mode;
+};
+
+enum MAX77802_RTC_OP {
+ MAX77802_RTC_WRITE,
+ MAX77802_RTC_READ,
+};
+
+static void max77802_rtc_data_to_tm(u8 *data, struct rtc_time *tm,
+ int rtc_24hr_mode)
+{
+ tm->tm_sec = data[RTC_SEC] & 0xff;
+ tm->tm_min = data[RTC_MIN] & 0xff;
+ if (rtc_24hr_mode)
+ tm->tm_hour = data[RTC_HOUR] & 0x1f;
+ else {
+ tm->tm_hour = data[RTC_HOUR] & 0x0f;
+ if (data[RTC_HOUR] & HOUR_PM_MASK)
+
[PATCH v10 5/6] rtc: max77686: Use ffs() to calculate tm_wday
The function max77686_rtc_calculate_wday() is used to
calculate the day of the week to be filled in struct
rtc_time but that function only calculates the number
of bits shifted. So the ffs() function can be used to
find the first bit set instead of a special function.
Signed-off-by: Javier Martinez Canillas
---
drivers/rtc/rtc-max77686.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index b177ba1..2659bd3 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -70,16 +70,6 @@ enum MAX77686_RTC_OP {
MAX77686_RTC_READ,
};
-static inline int max77686_rtc_calculate_wday(u8 shifted)
-{
- int counter = -1;
- while (shifted) {
- shifted >>= 1;
- counter++;
- }
- return counter;
-}
-
static void max77686_rtc_data_to_tm(u8 *data, struct rtc_time *tm,
int rtc_24hr_mode)
{
@@ -93,7 +83,7 @@ static void max77686_rtc_data_to_tm(u8 *data, struct rtc_time
*tm,
tm->tm_hour += 12;
}
- tm->tm_wday = max77686_rtc_calculate_wday(data[RTC_WEEKDAY] & 0x7f);
+ tm->tm_wday = ffs(data[RTC_WEEKDAY] & 0x7f) - 1;
tm->tm_mday = data[RTC_DATE] & 0x1f;
tm->tm_mon = (data[RTC_MONTH] & 0x0f) - 1;
tm->tm_year = (data[RTC_YEAR] & 0x7f) + 100;
--
2.1.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
[PATCH v10 2/6] rtc: max77686: Remove dead code for SMPL and WTSR.
The MAX77686 RTC chip has two features called SMPL (Sudden Momentary
Power Loss) and WTSR (Watchdog Timeout and Software Resets).
Support for these features seems to be implemented in the driver but
compilation is disabled using a C pre-processor conditional.
This code has been disabled since the driver was original merged in
commit fca1dd03 ("rtc: max77686: add Maxim 77686 driver").
So, since this code has never been built, let's just remove it.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Krzysztof Kozlowski
---
drivers/rtc/rtc-max77686.c | 101 -
1 file changed, 101 deletions(-)
diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index c1c6055..7bb5433 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -32,15 +32,6 @@
#define RTC_UDR_MASK (1 << RTC_UDR_SHIFT)
#define RTC_RBUDR_SHIFT4
#define RTC_RBUDR_MASK (1 << RTC_RBUDR_SHIFT)
-/* WTSR and SMPL Register */
-#define WTSRT_SHIFT0
-#define SMPLT_SHIFT2
-#define WTSR_EN_SHIFT 6
-#define SMPL_EN_SHIFT 7
-#define WTSRT_MASK (3 << WTSRT_SHIFT)
-#define SMPLT_MASK (3 << SMPLT_SHIFT)
-#define WTSR_EN_MASK (1 << WTSR_EN_SHIFT)
-#define SMPL_EN_MASK (1 << SMPL_EN_SHIFT)
/* RTC Hour register */
#define HOUR_PM_SHIFT 6
#define HOUR_PM_MASK (1 << HOUR_PM_SHIFT)
@@ -49,7 +40,6 @@
#define ALARM_ENABLE_MASK (1 << ALARM_ENABLE_SHIFT)
#define MAX77686_RTC_UPDATE_DELAY 16
-#undef MAX77686_RTC_WTSR_SMPL
enum {
RTC_SEC = 0,
@@ -412,64 +402,6 @@ static const struct rtc_class_ops max77686_rtc_ops = {
.alarm_irq_enable = max77686_rtc_alarm_irq_enable,
};
-#ifdef MAX77686_RTC_WTSR_SMPL
-static void max77686_rtc_enable_wtsr(struct max77686_rtc_info *info, bool
enable)
-{
- int ret;
- unsigned int val, mask;
-
- if (enable)
- val = (1 << WTSR_EN_SHIFT) | (3 << WTSRT_SHIFT);
- else
- val = 0;
-
- mask = WTSR_EN_MASK | WTSRT_MASK;
-
- dev_info(info->dev, "%s: %s WTSR\n", __func__,
- enable ? "enable" : "disable");
-
- ret = regmap_update_bits(info->max77686->rtc_regmap,
-MAX77686_WTSR_SMPL_CNTL, mask, val);
- if (ret < 0) {
- dev_err(info->dev, "%s: fail to update WTSR reg(%d)\n",
- __func__, ret);
- return;
- }
-
- max77686_rtc_update(info, MAX77686_RTC_WRITE);
-}
-
-static void max77686_rtc_enable_smpl(struct max77686_rtc_info *info, bool
enable)
-{
- int ret;
- unsigned int val, mask;
-
- if (enable)
- val = (1 << SMPL_EN_SHIFT) | (0 << SMPLT_SHIFT);
- else
- val = 0;
-
- mask = SMPL_EN_MASK | SMPLT_MASK;
-
- dev_info(info->dev, "%s: %s SMPL\n", __func__,
- enable ? "enable" : "disable");
-
- ret = regmap_update_bits(info->max77686->rtc_regmap,
-MAX77686_WTSR_SMPL_CNTL, mask, val);
- if (ret < 0) {
- dev_err(info->dev, "%s: fail to update SMPL reg(%d)\n",
- __func__, ret);
- return;
- }
-
- max77686_rtc_update(info, MAX77686_RTC_WRITE);
-
- val = 0;
- regmap_read(info->max77686->rtc_regmap, MAX77686_WTSR_SMPL_CNTL, &val);
- dev_info(info->dev, "%s: WTSR_SMPL(0x%02x)\n", __func__, val);
-}
-#endif /* MAX77686_RTC_WTSR_SMPL */
-
static int max77686_rtc_init_reg(struct max77686_rtc_info *info)
{
u8 data[2];
@@ -519,11 +451,6 @@ static int max77686_rtc_probe(struct platform_device *pdev)
goto err_rtc;
}
-#ifdef MAX77686_RTC_WTSR_SMPL
- max77686_rtc_enable_wtsr(info, true);
- max77686_rtc_enable_smpl(info, true);
-#endif
-
device_init_wakeup(&pdev->dev, 1);
info->rtc_dev = devm_rtc_device_register(&pdev->dev, "max77686-rtc",
@@ -556,33 +483,6 @@ err_rtc:
return ret;
}
-static void max77686_rtc_shutdown(struct platform_device *pdev)
-{
-#ifdef MAX77686_RTC_WTSR_SMPL
- struct max77686_rtc_info *info = platform_get_drvdata(pdev);
- int i;
- u8 val = 0;
-
- for (i = 0; i < 3; i++) {
- max77686_rtc_enable_wtsr(info, false);
- regmap_read(info->max77686->rtc_regmap,
MAX77686_WTSR_SMPL_CNTL, &val);
- dev_info(info->dev, "%s: WTSR_SMPL reg(0x%02x)\n", __func__,
- val);
- if (val & WTSR_EN_MASK) {
- dev_emerg(info->dev, "%s: fail to disable WTSR\n",
- __func__);
- } else {
- dev_info(info->dev, "%s: success to disa
[PATCH v10 4/6] rtc: max77686: Remove unneded info log
If devm_rtc_device_register() fails a dev_err() is already
reported so there is no need to do an additional dev_info().
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Krzysztof Kozlowski
---
drivers/rtc/rtc-max77686.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index 55396bb..b177ba1 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -457,8 +457,6 @@ static int max77686_rtc_probe(struct platform_device *pdev)
&max77686_rtc_ops, THIS_MODULE);
if (IS_ERR(info->rtc_dev)) {
- dev_info(&pdev->dev, "%s: fail\n", __func__);
-
ret = PTR_ERR(info->rtc_dev);
dev_err(&pdev->dev, "Failed to register RTC device: %d\n", ret);
if (ret == 0)
--
2.1.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
[PATCH v10 3/6] rtc: max77686: Fail to probe if no RTC regmap irqchip is set
The max77686 mfd driver adds a regmap IRQ chip which creates an
IRQ domain that is used to map the virtual RTC alarm1 interrupt.
The RTC driver assumes that this will always be true since the
PMIC IRQ is a required property according to the max77686 DT
binding doc. If an "interrupts" property is not defined for a
max77686 PMIC, then the mfd probe function will fail and the
RTC platform driver will never be probed. But even when it is
not possible to probe the rtc-max77686 driver without a regmap
IRQ chip, it's better to explicitly check if the IRQ chip data
is not NULL and gracefully fail instead of getting an OOPS.
Reported-by: Krzysztof Kozlowski
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Krzysztof Kozlowski
---
Fixes the issue reported by Krzystof in: https://lkml.org/lkml/2014/8/8/121
drivers/rtc/rtc-max77686.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index 7bb5433..55396bb 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -466,6 +466,12 @@ static int max77686_rtc_probe(struct platform_device *pdev)
goto err_rtc;
}
+ if (!max77686->rtc_irq_data) {
+ ret = -EINVAL;
+ dev_err(&pdev->dev, "%s: no RTC regmap IRQ chip\n", __func__);
+ goto err_rtc;
+ }
+
info->virq = regmap_irq_get_virq(max77686->rtc_irq_data,
MAX77686_RTCIRQ_RTCA1);
if (!info->virq) {
--
2.1.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
[PATCH v10 1/6] rtc: max77686: Allow the max77686 rtc to wakeup the system
From: Doug Anderson
The max77686 includes an RTC that keeps power during suspend. It's
convenient to be able to use it as a wakeup source.
Signed-off-by: Doug Anderson
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Javier Martinez Canillas
---
Changes since v9:
- Remove note from Doug that is not applicable anymore due changes in the
i2c driver.
- Add s-o-b since I'm in the patch delivery path. Suggested by Andrew Morton.
Changes since v8: None
Changes since v7: None
Changes since v6: None
Changes since v5:
- Fix $SUBJECT since the patch does not actually touch the mfd subsys.
Suggested by Lee Jones.
Changes since v4: None
Changes since v3:
- Keep the note that this patch needs another change due wakeup
ordering problems.
drivers/rtc/rtc-max77686.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index d20a7f0..c1c6055 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -583,6 +583,33 @@ static void max77686_rtc_shutdown(struct platform_device
*pdev)
#endif /* MAX77686_RTC_WTSR_SMPL */
}
+#ifdef CONFIG_PM_SLEEP
+static int max77686_rtc_suspend(struct device *dev)
+{
+ if (device_may_wakeup(dev)) {
+ struct max77686_rtc_info *info = dev_get_drvdata(dev);
+
+ return enable_irq_wake(info->virq);
+ }
+
+ return 0;
+}
+
+static int max77686_rtc_resume(struct device *dev)
+{
+ if (device_may_wakeup(dev)) {
+ struct max77686_rtc_info *info = dev_get_drvdata(dev);
+
+ return disable_irq_wake(info->virq);
+ }
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(max77686_rtc_pm_ops,
+max77686_rtc_suspend, max77686_rtc_resume);
+
static const struct platform_device_id rtc_id[] = {
{ "max77686-rtc", 0 },
{},
@@ -592,6 +619,7 @@ static struct platform_driver max77686_rtc_driver = {
.driver = {
.name = "max77686-rtc",
.owner = THIS_MODULE,
+ .pm = &max77686_rtc_pm_ops,
},
.probe = max77686_rtc_probe,
.shutdown = max77686_rtc_shutdown,
--
2.1.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] drm/exynos: switch to universal plane API
On 09/19/2014 03:02 AM, Joonyoung Shim wrote:
> Hi Andrzej,
>
> On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
>> The patch replaces legacy functions
>> drm_plane_init() / drm_crtc_init() with
>> drm_universal_plane_init() and drm_crtc_init_with_planes().
>> It allows to replace fake primary plane with the real one.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> Hi Inki,
>>
>> I have tested this patch with trats board, it looks OK.
>> As a side effect it should solve fb refcounting issues
>> reported by me and Daniel Drake.
>>
>> Regards
>> Andrzej
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 63
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++-
>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
>> drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +-
>> 4 files changed, 47 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index b68e58f..d2f713e 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
>> * Exynos specific crtc structure.
>> *
>> * @drm_crtc: crtc object.
>> - * @drm_plane: pointer of private plane object for this crtc
>> * @manager: the manager associated with this crtc
>> * @pipe: a crtc index created at load() with a new crtc object creation
>> * and the crtc object would be set to private->crtc array
>> @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
>> */
>> struct exynos_drm_crtc {
>> struct drm_crtc drm_crtc;
>> -struct drm_plane*plane;
>> struct exynos_drm_manager *manager;
>> unsigned intpipe;
>> unsigned intdpms;
>> @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
>>
>> exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>>
>> -exynos_plane_commit(exynos_crtc->plane);
>> +exynos_plane_commit(crtc->primary);
>>
>> if (manager->ops->commit)
>> manager->ops->commit(manager);
>>
>> -exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
>> +exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
>> }
>>
>> static bool
>> @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
>> drm_display_mode *mode,
>> {
>> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>> struct exynos_drm_manager *manager = exynos_crtc->manager;
>> -struct drm_plane *plane = exynos_crtc->plane;
>> +struct drm_framebuffer *fb = crtc->primary->fb;
>> unsigned int crtc_w;
>> unsigned int crtc_h;
>> -int ret;
>>
>> /*
>> * copy the mode data adjusted by mode_fixup() into crtc->mode
>> @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
>> drm_display_mode *mode,
>> */
>> memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode));
>>
>> -crtc_w = crtc->primary->fb->width - x;
>> -crtc_h = crtc->primary->fb->height - y;
>> +crtc_w = fb->width - x;
>> +crtc_h = fb->height - y;
>>
>> if (manager->ops->mode_set)
>> manager->ops->mode_set(manager, &crtc->mode);
>>
>> -ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
>> crtc_w, crtc_h,
>> -x, y, crtc_w, crtc_h);
>> -if (ret)
>> -return ret;
>> -
>> -plane->crtc = crtc;
>> -plane->fb = crtc->primary->fb;
>> -drm_framebuffer_reference(plane->fb);
>> -
>> -return 0;
>> +return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
>> + crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>> }
>>
>> static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x,
>> int y,
>>struct drm_framebuffer *old_fb)
>> {
>> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>> -struct drm_plane *plane = exynos_crtc->plane;
>> +struct drm_framebuffer *fb = crtc->primary->fb;
>> unsigned int crtc_w;
>> unsigned int crtc_h;
>> int ret;
>> @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct
>> drm_crtc *crtc, int x, int y,
>> return -EPERM;
>> }
>>
>> -crtc_w = crtc->primary->fb->width - x;
>> -crtc_h = crtc->primary->fb->height - y;
>> +crtc_w = fb->width - x;
>> +crtc_h = fb->height - y;
>>
>> -ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
>> crtc_w, crtc_h,
>> -x, y, crtc_w, crtc_h);
>> +ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
>> +crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>> if (ret)
>> return ret;
>>
>> @@ -279,6 +268,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc
>> *crtc)
>>
>> private->crtc[exynos_crtc->pipe] = NULL;
>
Re: [PATCH] drm/exynos: switch to universal plane API
Hi,
On 09/19/2014 07:54 PM, Andrzej Hajda wrote:
> On 09/19/2014 03:02 AM, Joonyoung Shim wrote:
>> Hi Andrzej,
>>
>> On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
>>> The patch replaces legacy functions
>>> drm_plane_init() / drm_crtc_init() with
>>> drm_universal_plane_init() and drm_crtc_init_with_planes().
>>> It allows to replace fake primary plane with the real one.
>>>
>>> Signed-off-by: Andrzej Hajda
>>> ---
>>> Hi Inki,
>>>
>>> I have tested this patch with trats board, it looks OK.
>>> As a side effect it should solve fb refcounting issues
>>> reported by me and Daniel Drake.
>>>
>>> Regards
>>> Andrzej
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 63
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++-
>>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
>>> drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +-
>>> 4 files changed, 47 insertions(+), 41 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> index b68e58f..d2f713e 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
>>> * Exynos specific crtc structure.
>>> *
>>> * @drm_crtc: crtc object.
>>> - * @drm_plane: pointer of private plane object for this crtc
>>> * @manager: the manager associated with this crtc
>>> * @pipe: a crtc index created at load() with a new crtc object creation
>>> * and the crtc object would be set to private->crtc array
>>> @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
>>> */
>>> struct exynos_drm_crtc {
>>> struct drm_crtc drm_crtc;
>>> - struct drm_plane*plane;
>>> struct exynos_drm_manager *manager;
>>> unsigned intpipe;
>>> unsigned intdpms;
>>> @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc
>>> *crtc)
>>>
>>> exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>>>
>>> - exynos_plane_commit(exynos_crtc->plane);
>>> + exynos_plane_commit(crtc->primary);
>>>
>>> if (manager->ops->commit)
>>> manager->ops->commit(manager);
>>>
>>> - exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
>>> + exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
>>> }
>>>
>>> static bool
>>> @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
>>> drm_display_mode *mode,
>>> {
>>> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>>> struct exynos_drm_manager *manager = exynos_crtc->manager;
>>> - struct drm_plane *plane = exynos_crtc->plane;
>>> + struct drm_framebuffer *fb = crtc->primary->fb;
>>> unsigned int crtc_w;
>>> unsigned int crtc_h;
>>> - int ret;
>>>
>>> /*
>>> * copy the mode data adjusted by mode_fixup() into crtc->mode
>>> @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc,
>>> struct drm_display_mode *mode,
>>> */
>>> memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode));
>>>
>>> - crtc_w = crtc->primary->fb->width - x;
>>> - crtc_h = crtc->primary->fb->height - y;
>>> + crtc_w = fb->width - x;
>>> + crtc_h = fb->height - y;
>>>
>>> if (manager->ops->mode_set)
>>> manager->ops->mode_set(manager, &crtc->mode);
>>>
>>> - ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
>>> crtc_w, crtc_h,
>>> - x, y, crtc_w, crtc_h);
>>> - if (ret)
>>> - return ret;
>>> -
>>> - plane->crtc = crtc;
>>> - plane->fb = crtc->primary->fb;
>>> - drm_framebuffer_reference(plane->fb);
>>> -
>>> - return 0;
>>> + return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
>>> +crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>>> }
>>>
>>> static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x,
>>> int y,
>>> struct drm_framebuffer *old_fb)
>>> {
>>> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>>> - struct drm_plane *plane = exynos_crtc->plane;
>>> + struct drm_framebuffer *fb = crtc->primary->fb;
>>> unsigned int crtc_w;
>>> unsigned int crtc_h;
>>> int ret;
>>> @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct
>>> drm_crtc *crtc, int x, int y,
>>> return -EPERM;
>>> }
>>>
>>> - crtc_w = crtc->primary->fb->width - x;
>>> - crtc_h = crtc->primary->fb->height - y;
>>> + crtc_w = fb->width - x;
>>> + crtc_h = fb->height - y;
>>>
>>> - ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
>>> crtc_w, crtc_h,
>>> - x, y, crtc_w, crtc_h);
>>> + ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
>>> + crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>>> if (ret)
>>> return ret;
>>>
>>> @@ -279,
RE: [PATCH v4 5/8] arm64: dts: Add initial device tree support for EXYNOS7
Naveen Krishna Chatradhi wrote:
>
> Add initial device tree nodes for EXYNOS7 SoC and board dts file
> to support Espresso board based on Exynos7 SoC.
>
> Signed-off-by: Naveen Krishna Chatradhi
> Cc: Rob Herring
> Cc: Catalin Marinas
Looks good to me,
Acked-by: Kukjin Kim
Thanks,
Kukjin
> ---
> arch/arm64/boot/dts/Makefile|1 +
> arch/arm64/boot/dts/exynos/Makefile |5 +
> arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 39 ++
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 160
> +++
> 4 files changed, 205 insertions(+)
> create mode 100644 arch/arm64/boot/dts/exynos/Makefile
> create mode 100644 arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> create mode 100644 arch/arm64/boot/dts/exynos/exynos7.dtsi
>
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index 309c3dc..b13bf21 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,5 +1,6 @@
> dts-dirs += apm
> dts-dirs += arm
> +dts-dirs += exynos
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/exynos/Makefile
> b/arch/arm64/boot/dts/exynos/Makefile
> new file mode 100644
> index 000..20310e5
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/Makefile
> @@ -0,0 +1,5 @@
> +dtb-$(CONFIG_ARCH_EXYNOS7) += exynos7-espresso.dtb
> +
> +always := $(dtb-y)
> +subdir-y := $(dts-dirs)
> +clean-files := *.dtb
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> b/arch/arm64/boot/dts/exynos/exynos7-
> espresso.dts
> new file mode 100644
> index 000..e2c8283
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> @@ -0,0 +1,39 @@
> +/*
> + * SAMSUNG Exynos7 Espresso board device tree source
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * 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.
> +*/
> +
> +/dts-v1/;
> +#include "exynos7.dtsi"
> +
> +/ {
> + model = "Samsung Exynos7 Espresso board based on EXYNOS7";
> + compatible = "samsung,exynos7-espresso", "samsung,exynos7";
> +
> + aliases {
> + serial0 = &serial_2;
> + };
> +
> + chosen {
> + linux,stdout-path = &serial_2;
> + };
> +
> + memory@4000 {
> + device_type = "memory";
> + reg = <0x0 0x4000 0x0 0xC000>;
> + };
> +};
> +
> +&fin_pll {
> + clock-frequency = <2400>;
> +};
> +
> +&serial_2 {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> new file mode 100644
> index 000..c5b1b86
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -0,0 +1,160 @@
> +/*
> + * SAMSUNG EXYNOS7 SoC device tree source
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * 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.
> + */
> +
> +#include
> +
> +/ {
> + compatible = "samsung,exynos7";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57", "arm,armv8";
> + enable-method = "psci";
> + reg = <0x0>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57", "arm,armv8";
> + enable-method = "psci";
> + reg = <0x1>;
> + };
> +
> + cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57", "arm,armv8";
> + enable-method = "psci";
> + reg = <0x2>;
> + };
> +
> + cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57", "arm,armv8";
> + enable-method = "psci";
> + reg = <0x3>;
> + };
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + soc: soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0 0 0x1800>;
> +
> + chipid@1000 {
> + compatible = "samsung,exynos4210-chipid";
> + reg = <0x1000 0x1
Re: [PATCH] drm/exynos: switch to universal plane API
Hi,
On 09/19/2014 08:11 PM, Joonyoung Shim wrote:
> Hi,
>
> On 09/19/2014 07:54 PM, Andrzej Hajda wrote:
>> On 09/19/2014 03:02 AM, Joonyoung Shim wrote:
>>> Hi Andrzej,
>>>
>>> On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
The patch replaces legacy functions
drm_plane_init() / drm_crtc_init() with
drm_universal_plane_init() and drm_crtc_init_with_planes().
It allows to replace fake primary plane with the real one.
Signed-off-by: Andrzej Hajda
---
Hi Inki,
I have tested this patch with trats board, it looks OK.
As a side effect it should solve fb refcounting issues
reported by me and Daniel Drake.
Regards
Andrzej
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 63
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +-
4 files changed, 47 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index b68e58f..d2f713e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -32,7 +32,6 @@ enum exynos_crtc_mode {
* Exynos specific crtc structure.
*
* @drm_crtc: crtc object.
- * @drm_plane: pointer of private plane object for this crtc
* @manager: the manager associated with this crtc
* @pipe: a crtc index created at load() with a new crtc object creation
*and the crtc object would be set to private->crtc array
@@ -46,7 +45,6 @@ enum exynos_crtc_mode {
*/
struct exynos_drm_crtc {
struct drm_crtc drm_crtc;
- struct drm_plane*plane;
struct exynos_drm_manager *manager;
unsigned intpipe;
unsigned intdpms;
@@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc
*crtc)
exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
- exynos_plane_commit(exynos_crtc->plane);
+ exynos_plane_commit(crtc->primary);
if (manager->ops->commit)
manager->ops->commit(manager);
- exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
+ exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
}
static bool
@@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *mode,
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_manager *manager = exynos_crtc->manager;
- struct drm_plane *plane = exynos_crtc->plane;
+ struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
- int ret;
/*
* copy the mode data adjusted by mode_fixup() into crtc->mode
@@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *mode,
*/
memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode));
- crtc_w = crtc->primary->fb->width - x;
- crtc_h = crtc->primary->fb->height - y;
+ crtc_w = fb->width - x;
+ crtc_h = fb->height - y;
if (manager->ops->mode_set)
manager->ops->mode_set(manager, &crtc->mode);
- ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
crtc_w, crtc_h,
- x, y, crtc_w, crtc_h);
- if (ret)
- return ret;
-
- plane->crtc = crtc;
- plane->fb = crtc->primary->fb;
- drm_framebuffer_reference(plane->fb);
-
- return 0;
+ return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
+ crtc_w, crtc_h, x, y, crtc_w, crtc_h);
}
static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x,
int y,
struct drm_framebuffer *old_fb)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- struct drm_plane *plane = exynos_crtc->plane;
+ struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
int ret;
@@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct
drm_crtc *crtc, int x, int y,
return -EPERM;
}
- crtc_w = crtc->primary->fb->width - x;
- crtc_h = crtc->primary->fb->height - y;
+ crtc_w = fb->width - x;
+ crtc_h = fb->height - y;
- ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
crtc_w, crtc_h,
- x, y, crtc_w, crtc_h);
+ ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
Re: [PATCH] drm/exynos: switch to universal plane API
On 09/19/2014 01:11 PM, Joonyoung Shim wrote:
> Hi,
>
> On 09/19/2014 07:54 PM, Andrzej Hajda wrote:
>> On 09/19/2014 03:02 AM, Joonyoung Shim wrote:
>>> Hi Andrzej,
>>>
>>> On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
The patch replaces legacy functions
drm_plane_init() / drm_crtc_init() with
drm_universal_plane_init() and drm_crtc_init_with_planes().
It allows to replace fake primary plane with the real one.
Signed-off-by: Andrzej Hajda
---
Hi Inki,
I have tested this patch with trats board, it looks OK.
As a side effect it should solve fb refcounting issues
reported by me and Daniel Drake.
Regards
Andrzej
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 63
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +-
4 files changed, 47 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index b68e58f..d2f713e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -32,7 +32,6 @@ enum exynos_crtc_mode {
* Exynos specific crtc structure.
*
* @drm_crtc: crtc object.
- * @drm_plane: pointer of private plane object for this crtc
* @manager: the manager associated with this crtc
* @pipe: a crtc index created at load() with a new crtc object creation
*and the crtc object would be set to private->crtc array
@@ -46,7 +45,6 @@ enum exynos_crtc_mode {
*/
struct exynos_drm_crtc {
struct drm_crtc drm_crtc;
- struct drm_plane*plane;
struct exynos_drm_manager *manager;
unsigned intpipe;
unsigned intdpms;
@@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc
*crtc)
exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
- exynos_plane_commit(exynos_crtc->plane);
+ exynos_plane_commit(crtc->primary);
if (manager->ops->commit)
manager->ops->commit(manager);
- exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
+ exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
}
static bool
@@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *mode,
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_manager *manager = exynos_crtc->manager;
- struct drm_plane *plane = exynos_crtc->plane;
+ struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
- int ret;
/*
* copy the mode data adjusted by mode_fixup() into crtc->mode
@@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *mode,
*/
memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode));
- crtc_w = crtc->primary->fb->width - x;
- crtc_h = crtc->primary->fb->height - y;
+ crtc_w = fb->width - x;
+ crtc_h = fb->height - y;
if (manager->ops->mode_set)
manager->ops->mode_set(manager, &crtc->mode);
- ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
crtc_w, crtc_h,
- x, y, crtc_w, crtc_h);
- if (ret)
- return ret;
-
- plane->crtc = crtc;
- plane->fb = crtc->primary->fb;
- drm_framebuffer_reference(plane->fb);
-
- return 0;
+ return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
+ crtc_w, crtc_h, x, y, crtc_w, crtc_h);
}
static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x,
int y,
struct drm_framebuffer *old_fb)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- struct drm_plane *plane = exynos_crtc->plane;
+ struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
int ret;
@@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct
drm_crtc *crtc, int x, int y,
return -EPERM;
}
- crtc_w = crtc->primary->fb->width - x;
- crtc_h = crtc->primary->fb->height - y;
+ crtc_w = fb->width - x;
+ crtc_h = fb->height - y;
- ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
crtc_w, crtc_h,
- x, y, crtc_w, crtc_h);
+ ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
+
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On 18/09/14 08:50, Ajay kumar wrote: >>> Why do we need a complex graph when it can be handled using a simple >>> phandle? >> >> Maybe in your case you can handle it with simple phandle. Can you >> guarantee that it's enough for everyone, on all platforms? > Yes, as of now exynos5420-peach-pit and exynos5250-spring boards use > this. In case of both, the phandle to bridge node is passed to the > exynos_dp node. > >> The point of the ports/endpoint graph is to also support more >> complicated scenarios. If you now create ps8622 bindings that do not >> support those graphs, the no one else using ps8622 can use >> ports/endpoint graphs either. >> >> Btw, is there an example how the bridge with these bindings is used in a >> board's .dts file? I couldn't find any example with a quick search. So >> it's unclear to me what the "simple phandle" actually is. > Please refer to the following link: > https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/tree/arch/arm/boot/dts/exynos5420-peach-pit.dts?id=samsung-dt#n129 > Let me know if you still think we would need to describe it as a complex > graph! Yes, I think so. I'm not the DRM maintainer, though. I think we have two options: 1) Describe the video component connections with the ports/endpoints properly for all new display device bindings, and know that it's (hopefully) future proof and covers even the more complex boards that use the devices. or 2) Use some simple methods to describe the links, like single phandle as you do, knowing that we can't support more complex boards in the future. I see some exynos boards already using the ports/endpoints, like arch/arm/boot/dts/exynos4412-trats2.dts. Why not use it for all new display devices? Tomi signature.asc Description: OpenPGP digital signature
[PATCH] drm/exynos: init vblank with real number of crtcs
Initialization of vblank with MAX_CRTC caused attempts to disabling vblanks for non-existing crtcs in case drm used fewer crtcs. The patch fixes it. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 9b00e4e..dc4affd 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -94,10 +94,6 @@ static int exynos_drm_load(struct drm_device *dev, unsigned long flags) /* init kms poll for handling hpd */ drm_kms_helper_poll_init(dev); - ret = drm_vblank_init(dev, MAX_CRTC); - if (ret) - goto err_mode_config_cleanup; - /* setup possible_clones. */ exynos_drm_encoder_setup(dev); @@ -106,22 +102,26 @@ static int exynos_drm_load(struct drm_device *dev, unsigned long flags) /* Try to bind all sub drivers. */ ret = component_bind_all(dev->dev, dev); if (ret) - goto err_cleanup_vblank; + goto err_mode_config_cleanup; + + ret = drm_vblank_init(dev, dev->mode_config.num_crtc); + if (ret) + goto err_unbind_all; /* Probe non kms sub drivers and virtual display driver. */ ret = exynos_drm_device_subdrv_probe(dev); if (ret) - goto err_unbind_all; + goto err_cleanup_vblank; /* force connectors detection */ drm_helper_hpd_irq_event(dev); return 0; -err_unbind_all: - component_unbind_all(dev->dev, dev); err_cleanup_vblank: drm_vblank_cleanup(dev); +err_unbind_all: + component_unbind_all(dev->dev, dev); err_mode_config_cleanup: drm_mode_config_cleanup(dev); drm_release_iommu_mapping(dev); @@ -138,8 +138,8 @@ static int exynos_drm_unload(struct drm_device *dev) exynos_drm_fbdev_fini(dev); drm_kms_helper_poll_fini(dev); - component_unbind_all(dev->dev, dev); drm_vblank_cleanup(dev); + component_unbind_all(dev->dev, dev); drm_mode_config_cleanup(dev); drm_release_iommu_mapping(dev); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] drm/exynos: switch to universal plane API
The patch replaces legacy functions
drm_plane_init() / drm_crtc_init() with
drm_universal_plane_init() and drm_crtc_init_with_planes().
It allows to replace fake primary plane with the real one.
Additionally the patch leaves cleanup of crtcs to core,
this way planes and crtcs are cleaned in correct order.
Signed-off-by: Andrzej Hajda
---
Hi Inki, Joonyoung,
This is 2nd version of the patch with addressed comments of Joonyoung.
Regards
Andrzej
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 62 +++
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 -
drivers/gpu/drm/exynos/exynos_drm_plane.c | 19 +-
drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 -
drivers/gpu/drm/exynos/exynos_mixer.c | 2 -
7 files changed, 46 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index b68e58f..8e38e9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -32,7 +32,6 @@ enum exynos_crtc_mode {
* Exynos specific crtc structure.
*
* @drm_crtc: crtc object.
- * @drm_plane: pointer of private plane object for this crtc
* @manager: the manager associated with this crtc
* @pipe: a crtc index created at load() with a new crtc object creation
* and the crtc object would be set to private->crtc array
@@ -46,7 +45,6 @@ enum exynos_crtc_mode {
*/
struct exynos_drm_crtc {
struct drm_crtc drm_crtc;
- struct drm_plane*plane;
struct exynos_drm_manager *manager;
unsigned intpipe;
unsigned intdpms;
@@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
- exynos_plane_commit(exynos_crtc->plane);
+ exynos_plane_commit(crtc->primary);
if (manager->ops->commit)
manager->ops->commit(manager);
- exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
+ exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
}
static bool
@@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_manager *manager = exynos_crtc->manager;
- struct drm_plane *plane = exynos_crtc->plane;
+ struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
- int ret;
/*
* copy the mode data adjusted by mode_fixup() into crtc->mode
@@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
*/
memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode));
- crtc_w = crtc->primary->fb->width - x;
- crtc_h = crtc->primary->fb->height - y;
+ crtc_w = fb->width - x;
+ crtc_h = fb->height - y;
if (manager->ops->mode_set)
manager->ops->mode_set(manager, &crtc->mode);
- ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
crtc_w, crtc_h,
- x, y, crtc_w, crtc_h);
- if (ret)
- return ret;
-
- plane->crtc = crtc;
- plane->fb = crtc->primary->fb;
- drm_framebuffer_reference(plane->fb);
-
- return 0;
+ return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
+crtc_w, crtc_h, x, y, crtc_w, crtc_h);
}
static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *old_fb)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- struct drm_plane *plane = exynos_crtc->plane;
+ struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
int ret;
@@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct
drm_crtc *crtc, int x, int y,
return -EPERM;
}
- crtc_w = crtc->primary->fb->width - x;
- crtc_h = crtc->primary->fb->height - y;
+ crtc_w = fb->width - x;
+ crtc_h = fb->height - y;
- ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
crtc_w, crtc_h,
- x, y, crtc_w, crtc_h);
+ ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
+ crtc_w, crtc_h, x, y, crtc_w, crtc_h);
if (ret)
return ret;
@@ -304,8 +293,7 @@ static int exynos_drm_crtc_set_property(struct drm_crtc
*crtc,
exynos_drm_crtc_commit(crtc);
break;
case CRTC_MODE_BLANK:
- exynos_plane_dpms(exyno
Re: [PATCH v7 00/11] kernel: Add support for restart handler call chain
Hello Guenter, Thanks for the patches. Tested patches 1,2 & 4 from this series on qcom apq8064 based IFC6410 with Josh's patches which replace arm restart with restart notifier for this target. Tested-by: pramod.gu...@smartplayin.com On Wednesday 20 August 2014 06:15 AM, Guenter Roeck wrote: > Various drivers implement architecture and/or device specific means > to restart (reset) the system. Various mechanisms have been implemented > to support those schemes. The best known mechanism is arm_pm_restart, > which is a function pointer to be set either from platform specific code > or from drivers. Another mechanism is to use hardware watchdogs to issue > a reset; this mechanism is used if there is no other method available > to reset a board or system. Two examples are alim7101_wdt, which currently > uses the reboot notifier to trigger a reset, and moxart_wdt, which registers > the arm_pm_restart function. Several other restart drivers for arm, all > directly calling arm_pm_restart, are in the process of being integrated > into the kernel. All those drivers would benefit from the new API. > > The existing mechanisms have a number of drawbacks. Typically only one scheme > to restart the system is supported (at least if arm_pm_restart is used). > At least in theory there can be multiple means to restart the system, some of > which may be less desirable (for example one mechanism may only reset the CPU, > while another may reset the entire system). Using arm_pm_restart can also be > racy if the function pointer is set from a driver, as the driver may be in > the process of being unloaded when arm_pm_restart is called. > Using the reboot notifier is always racy, as it is unknown if and when > other functions using the reboot notifier have completed execution > by the time the watchdog fires. > > Introduce a system restart handler call chain to solve the described problems. > This call chain is expected to be executed from the architecture specific > machine_restart() function. Drivers providing system restart functionality > (such as the watchdog drivers mentioned above) are expected to register > with this call chain. By using the priority field in the notifier block, > callers can control restart handler execution sequence and thus ensure that > the restart handler with the optimal restart capabilities for a given system > is called first. > > Since the first revision of this patchset, a number of separate patch > submissions have been made which either depend on it or could make use of it. > > http://www.spinics.net/linux/lists/arm-kernel/msg344796.html > registers three notifiers. > https://lkml.org/lkml/2014/7/8/962 > would benefit from it. > > Patch 1 of this series implements the restart handler function. Patches 2 and > 3 > implement calling the restart handler chain from arm and arm64 restart code. > > Patch 4 modifies the restart-poweroff driver to no longer call arm_pm_restart > directly but machine_restart. This is done to avoid calling arm_pm_restart > from more than one place. The change makes the driver architecture > independent, > so it would be possible to drop the arm dependency from its Kconfig entry. > > Patch 5 and 6 convert existing restart handlers in the watchdog subsystem > to use the restart handler. Patch 7 unexports arm_pm_restart to ensure > that no one gets the idea to implement a restart handler as module. > > The entire patch series, including additional patches depending on it, > is available from > https://git.kernel.org/cgit/linux/kernel/git/groeck/linux-staging.git/ > in branch 'restart-staging'. > > --- > v7: Rebased to v3.17-rc1 > Dropped null_restart from arm code to make arm_pm_restart truly optional > Reordered series. power/restart must be patched to not use arm_pm_restart > prior to making arm_pm_restart optional. > Added all pending patches to series > v6: Use atomic notifier call chain > Rebased series to v3.16 > v5: Rebased series to v3.16-rc5 > Function renames: > register_restart_notifier -> register_restart_handler > unregister_restart_notifier -> unregister_restart_handler > kernel_restart_notify -> do_kernel_restart > v4: Document restart notifier priorities > Select 128 as default priority for newly introduced notifiers > Fix checkpatch warning (line too long) in moxart patch > v3: Drop RFC. > Add kernel_restart_notify wrapper function to execute notifier > Improve documentation. > Move restart_notifier_list into kernel/reboot.c and make it static. > v2: Add patch 4. > Only call blocking notifier call chain if arm_pm_restart was not set. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in th
[PATCH v4] mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure where is can be probed and such non-DT based drivers can use
syscon_regmap_lookup_by_pdev API and get access to regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completly remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann
Suggested-by: Tomasz Figa
Tested-by: Vivek Gautam
Signed-off-by: Pankaj Dubey
---
Changes since v3:
- Addressed Arnd's comment for v2.
- Updated of_syscon_register for adding dev pointer in regmap_init_mmio.
- For early users created dummy platform device.
Changes since v2:
- Added back platform device support from syscon, with one change that
syscon will not be probed for DT based platform.
- Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
users of syscon will not be broken.
- Removed unwanted change in syscon.h.
- Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
Arnd Bergmann.
- Added Tested-by of Vivek Gautam for testing on Exynos platform.
Changes since v1:
- Removed of_syscon_unregister function.
- Modified of_syscon_register function and it will be used by syscon.c
to create syscon objects whenever required.
- Removed platform device support from syscon.
- Removed syscon_regmap_lookup_by_pdevname API support.
- As there are significant changes w.r.t patchset v1, I am taking over
author for this patchset from Tomasz Figa.
[1]: https://lkml.org/lkml/2014/9/2/299
drivers/mfd/syscon.c | 102 ++
1 file changed, 79 insertions(+), 23 deletions(-)
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ca15878..630de0a 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -22,33 +23,100 @@
#include
#include
#include
+#include
static struct platform_driver syscon_driver;
+static DEFINE_SPINLOCK(syscon_list_slock);
+static LIST_HEAD(syscon_list);
+
struct syscon {
+ struct device_node *np;
struct regmap *regmap;
+ struct list_head list;
+};
+
+static struct regmap_config syscon_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
};
-static int syscon_match_node(struct device *dev, void *data)
+static struct syscon *of_syscon_register(struct device_node *np)
{
- struct device_node *dn = data;
+ struct platform_device *pdev = NULL;
+ struct syscon *syscon;
+ struct regmap *regmap;
+ void __iomem *base;
+
+
+ if (!of_device_is_compatible(np, "syscon"))
+ return ERR_PTR(-EINVAL);
+
+ syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
+ if (!syscon)
+ return ERR_PTR(-ENOMEM);
+
+ base = of_iomap(np, 0);
+ if (!base)
+ return ERR_PTR(-ENOMEM);
+
+ if (!of_device_is_available(np) ||
+ of_node_test_and_set_flag(np, OF_POPULATED)) {
+ /* if device is already populated and avaiable then use it */
+ pdev = of_find_device_by_node(np);
+ if (!(&pdev->dev))
+ return ERR_PTR(-ENODEV);
+
+ } else {
+ /* for early users create dummy syscon device and use it */
+ pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
+ if (!pdev)
+ return ERR_PTR(-ENOMEM);
+
+ pdev->name = "dummy-syscon";
+ pdev->id = -1;
+ device_initialize(&pdev->dev);
+ pdev->dev.of_node = np;
+ }
+
+ regmap = regmap_init_mmio(&pdev->dev, base, &syscon_regmap_config);
+ if (IS_ERR(regmap)) {
+ pr_err("regmap init failed\n");
+ return ERR_CAST(regmap);
+ }
+
+ syscon->regmap = regmap;
+
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On Fri, Sep 19, 2014 at 6:24 PM, Tomi Valkeinen wrote: > On 18/09/14 08:50, Ajay kumar wrote: > Why do we need a complex graph when it can be handled using a simple phandle? >>> >>> Maybe in your case you can handle it with simple phandle. Can you >>> guarantee that it's enough for everyone, on all platforms? >> Yes, as of now exynos5420-peach-pit and exynos5250-spring boards use >> this. In case of both, the phandle to bridge node is passed to the >> exynos_dp node. >> >>> The point of the ports/endpoint graph is to also support more >>> complicated scenarios. If you now create ps8622 bindings that do not >>> support those graphs, the no one else using ps8622 can use >>> ports/endpoint graphs either. >>> >>> Btw, is there an example how the bridge with these bindings is used in a >>> board's .dts file? I couldn't find any example with a quick search. So >>> it's unclear to me what the "simple phandle" actually is. >> Please refer to the following link: >> https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/tree/arch/arm/boot/dts/exynos5420-peach-pit.dts?id=samsung-dt#n129 >> Let me know if you still think we would need to describe it as a complex >> graph! > > Yes, I think so. I'm not the DRM maintainer, though. > > I think we have two options: > > 1) Describe the video component connections with the ports/endpoints > properly for all new display device bindings, and know that it's > (hopefully) future proof and covers even the more complex boards that > use the devices. > > or > > 2) Use some simple methods to describe the links, like single phandle as > you do, knowing that we can't support more complex boards in the future. I am not really able to understand, what's stopping us from using this bridge on a board with "complex" display connections. To use ps8622 driver, one needs to "attach" it to the DRM framework. For this, the DRM driver would need the DT node for ps8622 bridge. For which I use a phandle. If some XYZ platform wishes to pick the DT node via a different method, they are always welcome to do it. Just because I am not specifying a video port/endpoint in the DT binding example, would it mean that platform cannot make use of ports in future? If that is the case, I can add something like this: http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/panel/samsung,ld9040.txt#L61 Regards, Ajay kumar > I see some exynos boards already using the ports/endpoints, like > arch/arm/boot/dts/exynos4412-trats2.dts. Why not use it for all new > display devices? > > Tomi > > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] mfd: syscon: Decouple syscon interface from platform devices
Hello Pankaj, On Fri, Sep 19, 2014 at 3:06 PM, Pankaj Dubey wrote: > Currently a syscon entity can be only registered directly through a > platform device that binds to a dedicated syscon driver. However in > certain use cases it is desirable to make a device used with another > driver a syscon interface provider. > > For example, certain SoCs (e.g. Exynos) contain system controller > blocks which perform various functions such as power domain control, > CPU power management, low power mode control, but in addition contain > certain IP integration glue, such as various signal masks, > coprocessor power control, etc. In such case, there is a need to have > a dedicated driver for such system controller but also share registers > with other drivers. The latter is where the syscon interface is helpful. > > In case of DT based platforms, this patch decouples syscon object from > syscon platform driver, and allows to create syscon objects first time > when it is required by calling of syscon_regmap_lookup_by APIs and keep > a list of such syscon objects along with syscon provider device_nodes > and regmap handles. > > For non-DT based platforms, this patch keeps syscon platform driver > structure where is can be probed and such non-DT based drivers can use > syscon_regmap_lookup_by_pdev API and get access to regmap handles. > Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based, > we can completly remove platform driver of syscon, and keep only helper > functions to get regmap handles. > > Suggested-by: Arnd Bergmann > Suggested-by: Tomasz Figa > Tested-by: Vivek Gautam > Signed-off-by: Pankaj Dubey > --- > Changes since v3: > - Addressed Arnd's comment for v2. > - Updated of_syscon_register for adding dev pointer in regmap_init_mmio. > - For early users created dummy platform device. > > Changes since v2: > - Added back platform device support from syscon, with one change that >syscon will not be probed for DT based platform. > - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base >users of syscon will not be broken. > - Removed unwanted change in syscon.h. > - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and >Arnd Bergmann. > - Added Tested-by of Vivek Gautam for testing on Exynos platform. > > Changes since v1: > - Removed of_syscon_unregister function. > - Modified of_syscon_register function and it will be used by syscon.c >to create syscon objects whenever required. > - Removed platform device support from syscon. > - Removed syscon_regmap_lookup_by_pdevname API support. > - As there are significant changes w.r.t patchset v1, I am taking over >author for this patchset from Tomasz Figa. > > [1]: https://lkml.org/lkml/2014/9/2/299 > drivers/mfd/syscon.c | 102 > ++ > 1 file changed, 79 insertions(+), 23 deletions(-) > I tested this patch on an Exynos5420 Peach Pit Chromebook and I see that of_syscon_register() is called for the PMU system controller with compatible string "samsung,exynos5420-pmu", "syscon" which does not have a dedicated platform driver, so: Tested-by: Javier Martinez Canillas Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On 19/09/14 16:59, Ajay kumar wrote: > I am not really able to understand, what's stopping us from using this > bridge on a board with "complex" display connections. To use ps8622 driver, > one needs to "attach" it to the DRM framework. For this, the DRM driver Remember that when we talk about DT bindings, there's no such thing as DRM. We talk about hardware. The same bindings need to work on any operating system. > would need the DT node for ps8622 bridge. For which I use a phandle. A complex one could be for example a case where you have two different panels connected to ps8622, and you can switch between the two panels with, say, a gpio. How do you present that with a simple phandle? In the exynos5420-peach-pit.dts, which you linked earlier, I see a "panel" property in the ps8625 node. That's missing from the bindings in this patch. Why is that? How is the panel linked in this version? > If some XYZ platform wishes to pick the DT node via a different method, > they are always welcome to do it. Just because I am not specifying a > video port/endpoint in the DT binding example, would it mean that platform > cannot make use of ports in future? If that is the case, I can add something All the platforms share the same bindings for ps8622. If you now specify that ps8622 bindings use a simple phandle, then anyone who uses ps8622 should support that. Of course the bindings can be extended in the future. In that case the drivers need to support both the old and the new bindings, which is always a hassle. Generally speaking, I sense that we have different views of how display devices and drivers are structured. You say "If some XYZ platform wishes to pick the DT node via a different method, they are always welcome to do it.". This sounds to me that you see the connections between display devices as something handled by a platform specific driver. I, on the other hand, see connections between display devices as common properties. Say, we could have a display board, with a panel and an encoder and maybe some other components, which takes parallel RGB as input. The same display board could as well be connected to an OMAP board or to an Exynos board. I think the exact same display-board.dtsi file, which describes the devices and connections in the display board, should be usable on both OMAP and Exynos platforms. This means we need to have a common way to describe video devices, just as we have for other things. Tomi signature.asc Description: OpenPGP digital signature
RE: ASoC: samsung: MACH_SMDKC100
Paul Bolle wrote:
>
> Hi Kukjin,
>
Hi,
> On Sat, 2014-07-19 at 04:03 +0900, Kukjin Kim wrote:
> > On 07/18/14 17:55, Paul Bolle wrote:
> > > On Wed, 2014-07-02 at 10:01 +0200, Paul Bolle wrote:
> > >> Your commit 52ad6582ceb2 ("ARM: S5PC100: no more support S5PC100 SoC"
> > >> landed in next-20140702. It removed the Kconfig symbol MACH_SMDKC100
> > >> (and a lot of other stuff).
> > >>
> > >> Is the trivial patch to also remove the last two references to
> > >> MACH_SMDKC100 from sound/soc/samsung/Kconfig/ queued somewhere? I don't
> > >> think it was part of the series that included the above commit.
> > >
> > > Have you had time to look at this? Those last two references to
> > > MACH_SMDKC100 can still be seen in next-20140718.
> > >
> > Yeah you're right. The MACH_SMDKC100 is no more required...
> >
> > I submitted its fixup to Mark and I think he will take it for v3.17.
>
> What ever happened to that fixup? There are still (pointless) references
> to MACH_SMDKC100 in v3.17-rc5 and in next-20140918.
>
OhMark, what's wrong?
- Kukjin
--
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 v10 5/6] rtc: max77686: Use ffs() to calculate tm_wday
On Fri, 2014-09-19 at 12:26 +0200, Javier Martinez Canillas wrote:
> The function max77686_rtc_calculate_wday() is used to
> calculate the day of the week to be filled in struct
> rtc_time but that function only calculates the number
> of bits shifted. So the ffs() function can be used to
> find the first bit set instead of a special function.
This isn't the same logic. Perhaps you want fls.
> diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
[]
> -static inline int max77686_rtc_calculate_wday(u8 shifted)
> -{
> - int counter = -1;
> - while (shifted) {
> - shifted >>= 1;
> - counter++;
> - }
> - return counter;
> -}
> -
> static void max77686_rtc_data_to_tm(u8 *data, struct rtc_time *tm,
> int rtc_24hr_mode)
> {
> @@ -93,7 +83,7 @@ static void max77686_rtc_data_to_tm(u8 *data, struct
> rtc_time *tm,
> tm->tm_hour += 12;
> }
>
> - tm->tm_wday = max77686_rtc_calculate_wday(data[RTC_WEEKDAY] & 0x7f);
> + tm->tm_wday = ffs(data[RTC_WEEKDAY] & 0x7f) - 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] mfd: syscon: Decouple syscon interface from platform devices
Hi Pankaj,
Please see my comments inline.
On 19.09.2014 15:06, Pankaj Dubey wrote:
> Currently a syscon entity can be only registered directly through a
> platform device that binds to a dedicated syscon driver. However in
> certain use cases it is desirable to make a device used with another
> driver a syscon interface provider.
[snip]
> -static int syscon_match_node(struct device *dev, void *data)
> +static struct syscon *of_syscon_register(struct device_node *np)
> {
> - struct device_node *dn = data;
> + struct platform_device *pdev = NULL;
> + struct syscon *syscon;
> + struct regmap *regmap;
> + void __iomem *base;
> +
> +
nit: Stray blank line.
> + if (!of_device_is_compatible(np, "syscon"))
> + return ERR_PTR(-EINVAL);
I don't think this check is needed at all. I'd say that drivers should
be free to register a syscon provider for any node.
> +
> + syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
> + if (!syscon)
> + return ERR_PTR(-ENOMEM);
> +
> + base = of_iomap(np, 0);
> + if (!base)
> + return ERR_PTR(-ENOMEM);
> +
> + if (!of_device_is_available(np) ||
Wouldn't it be enough to simply call of_find_device_by_node(np) and if
it fails then instead create a dummy device?
> + of_node_test_and_set_flag(np, OF_POPULATED)) {
> + /* if device is already populated and avaiable then use it */
> + pdev = of_find_device_by_node(np);
> + if (!(&pdev->dev))
This is just plain wrong, because this condition will always evaluate to
true (see the definition of struct platform_device). Shouldn't you
rather just check the pdev pointer?
> + return ERR_PTR(-ENODEV);
> +
> + } else {
> + /* for early users create dummy syscon device and use it */
> + pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
> + if (!pdev)
> + return ERR_PTR(-ENOMEM);
Any clean-up on error path?
> +
> + pdev->name = "dummy-syscon";
> + pdev->id = -1;
Wouldn't you get an ID collision if more than one syscon is registered
early? Maybe the naming scheme from of_device_alloc() could be adopted
partially?
> + device_initialize(&pdev->dev);
I wonder if you couldn't simply reuse platform_device_alloc() for all of
this, except the line below, which would still have to be handled
separately.
> + pdev->dev.of_node = np;
> + }
> +
> + regmap = regmap_init_mmio(&pdev->dev, base, &syscon_regmap_config);
> + if (IS_ERR(regmap)) {
> + pr_err("regmap init failed\n");
If you have a dev here then you should be able to use dev_err() already.
> + return ERR_CAST(regmap);
> + }
> +
> + syscon->regmap = regmap;
> + syscon->np = np;
>
> - return (dev->of_node == dn) ? 1 : 0;
> + spin_lock(&syscon_list_slock);
> + list_add_tail(&syscon->list, &syscon_list);
> + spin_unlock(&syscon_list_slock);
> +
> + return syscon;
> }
>
> struct regmap *syscon_node_to_regmap(struct device_node *np)
> {
> - struct syscon *syscon;
> - struct device *dev;
> + struct syscon *entry, *syscon = NULL;
>
> - dev = driver_find_device(&syscon_driver.driver, NULL, np,
> - syscon_match_node);
> - if (!dev)
> - return ERR_PTR(-EPROBE_DEFER);
> + spin_lock(&syscon_list_slock);
>
> - syscon = dev_get_drvdata(dev);
> + list_for_each_entry(entry, &syscon_list, list)
> + if (entry->np == np) {
> + syscon = entry;
> + break;
> + }
>
> - return syscon->regmap;
> + spin_unlock(&syscon_list_slock);
> +
> + if (!syscon)
> + syscon = of_syscon_register(np);
> +
> + if (!IS_ERR(syscon))
> + return syscon->regmap;
> +
> + return ERR_CAST(syscon);
nit: Usually error checking is done the opposite way, i.e.
if (IS_ERR(syscon))
return ERR_CAST(syscon);
return syscon->regmap;
Best regards,
Tomasz
--
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] drm/exynos: init vblank with real number of crtcs
On Fri, Sep 19, 2014 at 02:57:20PM +0200, Andrzej Hajda wrote: > Initialization of vblank with MAX_CRTC caused attempts > to disabling vblanks for non-existing crtcs in case > drm used fewer crtcs. The patch fixes it. > > Signed-off-by: Andrzej Hajda > --- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c > b/drivers/gpu/drm/exynos/exynos_drm_drv.c > index 9b00e4e..dc4affd 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c > @@ -94,10 +94,6 @@ static int exynos_drm_load(struct drm_device *dev, > unsigned long flags) > /* init kms poll for handling hpd */ > drm_kms_helper_poll_init(dev); > > - ret = drm_vblank_init(dev, MAX_CRTC); > - if (ret) > - goto err_mode_config_cleanup; > - > /* setup possible_clones. */ > exynos_drm_encoder_setup(dev); > > @@ -106,22 +102,26 @@ static int exynos_drm_load(struct drm_device *dev, > unsigned long flags) > /* Try to bind all sub drivers. */ > ret = component_bind_all(dev->dev, dev); > if (ret) > - goto err_cleanup_vblank; > + goto err_mode_config_cleanup; > + > + ret = drm_vblank_init(dev, dev->mode_config.num_crtc); Hm, I wonder whether we should have a drm_mode_vblank_init which dtrt here for kms drivers? Suggestions for a better name welcome ;-) -Daniel > + if (ret) > + goto err_unbind_all; > > /* Probe non kms sub drivers and virtual display driver. */ > ret = exynos_drm_device_subdrv_probe(dev); > if (ret) > - goto err_unbind_all; > + goto err_cleanup_vblank; > > /* force connectors detection */ > drm_helper_hpd_irq_event(dev); > > return 0; > > -err_unbind_all: > - component_unbind_all(dev->dev, dev); > err_cleanup_vblank: > drm_vblank_cleanup(dev); > +err_unbind_all: > + component_unbind_all(dev->dev, dev); > err_mode_config_cleanup: > drm_mode_config_cleanup(dev); > drm_release_iommu_mapping(dev); > @@ -138,8 +138,8 @@ static int exynos_drm_unload(struct drm_device *dev) > exynos_drm_fbdev_fini(dev); > drm_kms_helper_poll_fini(dev); > > - component_unbind_all(dev->dev, dev); > drm_vblank_cleanup(dev); > + component_unbind_all(dev->dev, dev); > drm_mode_config_cleanup(dev); > drm_release_iommu_mapping(dev); > > -- > 1.9.1 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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 v2] drm/exynos: switch to universal plane API
2014-09-19 21:58 GMT+09:00 Andrzej Hajda :
> The patch replaces legacy functions
> drm_plane_init() / drm_crtc_init() with
> drm_universal_plane_init() and drm_crtc_init_with_planes().
> It allows to replace fake primary plane with the real one.
> Additionally the patch leaves cleanup of crtcs to core,
> this way planes and crtcs are cleaned in correct order.
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi Inki, Joonyoung,
>
> This is 2nd version of the patch with addressed comments of Joonyoung.
Picked it up.
Thanks,
Inki Dae
>
> Regards
> Andrzej
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 62
> +++
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++-
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 -
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 19 +-
> drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +-
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 -
> drivers/gpu/drm/exynos/exynos_mixer.c | 2 -
> 7 files changed, 46 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index b68e58f..8e38e9f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
> * Exynos specific crtc structure.
> *
> * @drm_crtc: crtc object.
> - * @drm_plane: pointer of private plane object for this crtc
> * @manager: the manager associated with this crtc
> * @pipe: a crtc index created at load() with a new crtc object creation
> * and the crtc object would be set to private->crtc array
> @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
> */
> struct exynos_drm_crtc {
> struct drm_crtc drm_crtc;
> - struct drm_plane*plane;
> struct exynos_drm_manager *manager;
> unsigned intpipe;
> unsigned intdpms;
> @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
>
> exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>
> - exynos_plane_commit(exynos_crtc->plane);
> + exynos_plane_commit(crtc->primary);
>
> if (manager->ops->commit)
> manager->ops->commit(manager);
>
> - exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
> + exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
> }
>
> static bool
> @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
> drm_display_mode *mode,
> {
> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> struct exynos_drm_manager *manager = exynos_crtc->manager;
> - struct drm_plane *plane = exynos_crtc->plane;
> + struct drm_framebuffer *fb = crtc->primary->fb;
> unsigned int crtc_w;
> unsigned int crtc_h;
> - int ret;
>
> /*
> * copy the mode data adjusted by mode_fixup() into crtc->mode
> @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
> drm_display_mode *mode,
> */
> memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode));
>
> - crtc_w = crtc->primary->fb->width - x;
> - crtc_h = crtc->primary->fb->height - y;
> + crtc_w = fb->width - x;
> + crtc_h = fb->height - y;
>
> if (manager->ops->mode_set)
> manager->ops->mode_set(manager, &crtc->mode);
>
> - ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
> crtc_w, crtc_h,
> - x, y, crtc_w, crtc_h);
> - if (ret)
> - return ret;
> -
> - plane->crtc = crtc;
> - plane->fb = crtc->primary->fb;
> - drm_framebuffer_reference(plane->fb);
> -
> - return 0;
> + return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
> +crtc_w, crtc_h, x, y, crtc_w, crtc_h);
> }
>
> static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, int
> y,
> struct drm_framebuffer *old_fb)
> {
> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> - struct drm_plane *plane = exynos_crtc->plane;
> + struct drm_framebuffer *fb = crtc->primary->fb;
> unsigned int crtc_w;
> unsigned int crtc_h;
> int ret;
> @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct
> drm_crtc *crtc, int x, int y,
> return -EPERM;
> }
>
> - crtc_w = crtc->primary->fb->width - x;
> - crtc_h = crtc->primary->fb->height - y;
> + crtc_w = fb->width - x;
> + crtc_h = fb->height - y;
>
> - ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
> crtc_w, crtc_h,
> - x, y, crtc_w, crtc_h);
> + ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
> + crtc_w, crtc_h, x, y, crtc_w, crt
Re: [PATCH v2] drm/exynos: switch to universal plane API
2014-09-20 1:04 GMT+09:00 Inki Dae :
> 2014-09-19 21:58 GMT+09:00 Andrzej Hajda :
>> The patch replaces legacy functions
>> drm_plane_init() / drm_crtc_init() with
>> drm_universal_plane_init() and drm_crtc_init_with_planes().
>> It allows to replace fake primary plane with the real one.
>> Additionally the patch leaves cleanup of crtcs to core,
>> this way planes and crtcs are cleaned in correct order.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> Hi Inki, Joonyoung,
>>
>> This is 2nd version of the patch with addressed comments of Joonyoung.
>
> Picked it up.
Oops, one more thing, there are trivial issues below. See the below
comments. Anyway, I fixed them up and merged.
Thanks,
Inki Dae
>
> Thanks,
> Inki Dae
>
>>
>> Regards
>> Andrzej
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 62
>> +++
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++-
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 -
>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 19 +-
>> drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +-
>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 -
>> drivers/gpu/drm/exynos/exynos_mixer.c | 2 -
>> 7 files changed, 46 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index b68e58f..8e38e9f 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
>> * Exynos specific crtc structure.
>> *
>> * @drm_crtc: crtc object.
>> - * @drm_plane: pointer of private plane object for this crtc
>> * @manager: the manager associated with this crtc
>> * @pipe: a crtc index created at load() with a new crtc object creation
>> * and the crtc object would be set to private->crtc array
>> @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
>> */
>> struct exynos_drm_crtc {
>> struct drm_crtc drm_crtc;
>> - struct drm_plane*plane;
>> struct exynos_drm_manager *manager;
>> unsigned intpipe;
>> unsigned intdpms;
>> @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
>>
>> exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>>
>> - exynos_plane_commit(exynos_crtc->plane);
>> + exynos_plane_commit(crtc->primary);
>>
>> if (manager->ops->commit)
>> manager->ops->commit(manager);
>>
>> - exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
>> + exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
>> }
>>
>> static bool
>> @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
>> drm_display_mode *mode,
>> {
>> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>> struct exynos_drm_manager *manager = exynos_crtc->manager;
>> - struct drm_plane *plane = exynos_crtc->plane;
>> + struct drm_framebuffer *fb = crtc->primary->fb;
>> unsigned int crtc_w;
>> unsigned int crtc_h;
>> - int ret;
>>
>> /*
>> * copy the mode data adjusted by mode_fixup() into crtc->mode
>> @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
>> drm_display_mode *mode,
>> */
>> memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode));
>>
>> - crtc_w = crtc->primary->fb->width - x;
>> - crtc_h = crtc->primary->fb->height - y;
>> + crtc_w = fb->width - x;
>> + crtc_h = fb->height - y;
>>
>> if (manager->ops->mode_set)
>> manager->ops->mode_set(manager, &crtc->mode);
>>
>> - ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
>> crtc_w, crtc_h,
>> - x, y, crtc_w, crtc_h);
>> - if (ret)
>> - return ret;
>> -
>> - plane->crtc = crtc;
>> - plane->fb = crtc->primary->fb;
>> - drm_framebuffer_reference(plane->fb);
>> -
>> - return 0;
>> + return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
>> +crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>> }
>>
>> static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x,
>> int y,
>> struct drm_framebuffer *old_fb)
>> {
>> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>> - struct drm_plane *plane = exynos_crtc->plane;
>> + struct drm_framebuffer *fb = crtc->primary->fb;
>> unsigned int crtc_w;
>> unsigned int crtc_h;
>> int ret;
>> @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct
>> drm_crtc *crtc, int x, int y,
>> return -EPERM;
>> }
>>
>> - crtc_w = crtc->primary->fb->width - x;
>> - crtc_h = crtc->primary->fb->height - y;
>> + crtc_w = fb->width - x;
>> + crtc_h = fb->height
Re: [PATCH v4 4/7] ARM: l2c: Add support for overriding prefetch settings
On Fri, Sep 19, 2014 at 11:50:01AM +0200, Alexandre Belloni wrote: > On 26/08/2014 at 16:17:57 +0200, Tomasz Figa wrote : > > Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch > > settings configured in registers leading to crashes if L2C is enabled > > without overriding them. This patch introduces bindings to enable > > prefetch settings to be specified from DT and necessary support in the > > driver. > > > > Signed-off-by: Tomasz Figa > > Tested-by: Alexandre Belloni > > It is working and useful on Atmel's sama5d4 were the bootloader is not > configuring the L2C prefetch. However, I'm wondering whether we should > add support for setting L310_PREFETCH_CTRL_DATA_PREFETCH and > L310_PREFETCH_CTRL_INSTR_PREFETCH. I'm currently doing it by using > ".l2c_aux_val= L310_AUX_CTRL_DATA_PREFETCH | > L310_AUX_CTRL_INSTR_PREFETCH" (those are the same bits) but this has the > disadvantage of displaying the "L2C: platform modifies aux control > register:" twice. The L2C documentation, freely available from the ARM infocentre website, has the answer to this for you. The two bits in the prefetch control register which control the data and instruction prefetching are aliases of the aux control register. If you set them to a value in one register, they are reflected in the other. The reason for that is that once the L2 cache is enabled, writes to the aux control register are no longer permitted, but it's safe to enable and disable the prefetching with the cache already enabled. This reason is even stated in the documentation. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] mfd: syscon: Decouple syscon interface from platform devices
On 19.09.2014 17:11, Tomasz Figa wrote:
>> +
>> +if (!of_device_is_available(np) ||
>
> Wouldn't it be enough to simply call of_find_device_by_node(np) and if
> it fails then instead create a dummy device?
>
>> +of_node_test_and_set_flag(np, OF_POPULATED)) {
One more thing I forgot to mention, the call to
of_node_test_and_set_flag() is also wrong, because it sets the flag,
marking the device as already populated, while it isn't.
Best regards,
Tomasz
--
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 v5 10/11] ARM: exynos: Move to generic PM domain DT bindings
From: Tomasz Figa
This patch moves Exynos PM domain code to use the new generic PM domain
look-up framework introduced in previous patches, thus also allowing
the new code to be compiled with CONFIG_ARCH_EXYNOS.
This patch was originally submitted by Tomasz Figa when he was employed
by Samsung.
http://marc.info/?l=linux-pm&m=139955336002083&w=2
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Ulf Hansson
Reviewed-by: Kevin Hilman
---
.../bindings/arm/exynos/power_domain.txt | 13 ++--
arch/arm/mach-exynos/pm_domains.c | 78 +-
kernel/power/Kconfig | 2 +-
3 files changed, 8 insertions(+), 85 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 8b4f7b7f..abde1ea 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -8,6 +8,8 @@ Required Properties:
* samsung,exynos4210-pd - for exynos4210 type power domain.
- reg: physical base address of the controller and length of memory mapped
region.
+- #power-domain-cells: number of cells in power domain specifier;
+must be 0.
Optional Properties:
- clocks: List of clock handles. The parent clocks of the input clocks to the
@@ -29,6 +31,7 @@ Example:
lcd0: power-domain-lcd0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C00 0x10>;
+ #power-domain-cells = <0>;
};
mfc_pd: power-domain@10044060 {
@@ -37,12 +40,8 @@ Example:
clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>,
<&clock CLK_MOUT_USER_ACLK333>;
clock-names = "oscclk", "pclk0", "clk0";
+ #power-domain-cells = <0>;
};
-Example of the node using power domain:
-
- node {
- /* ... */
- samsung,power-domain = <&lcd0>;
- /* ... */
- };
+See Documentation/devicetree/bindings/power/power_domain.txt for description
+of consumer-side bindings.
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index fd76e1b..20f2671 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -105,78 +105,6 @@ static int exynos_pd_power_off(struct generic_pm_domain
*domain)
return exynos_pd_power(domain, false);
}
-static void exynos_add_device_to_domain(struct exynos_pm_domain *pd,
-struct device *dev)
-{
- int ret;
-
- dev_dbg(dev, "adding to power domain %s\n", pd->pd.name);
-
- while (1) {
- ret = pm_genpd_add_device(&pd->pd, dev);
- if (ret != -EAGAIN)
- break;
- cond_resched();
- }
-
- pm_genpd_dev_need_restore(dev, true);
-}
-
-static void exynos_remove_device_from_domain(struct device *dev)
-{
- struct generic_pm_domain *genpd = dev_to_genpd(dev);
- int ret;
-
- dev_dbg(dev, "removing from power domain %s\n", genpd->name);
-
- while (1) {
- ret = pm_genpd_remove_device(genpd, dev);
- if (ret != -EAGAIN)
- break;
- cond_resched();
- }
-}
-
-static void exynos_read_domain_from_dt(struct device *dev)
-{
- struct platform_device *pd_pdev;
- struct exynos_pm_domain *pd;
- struct device_node *node;
-
- node = of_parse_phandle(dev->of_node, "samsung,power-domain", 0);
- if (!node)
- return;
- pd_pdev = of_find_device_by_node(node);
- if (!pd_pdev)
- return;
- pd = platform_get_drvdata(pd_pdev);
- exynos_add_device_to_domain(pd, dev);
-}
-
-static int exynos_pm_notifier_call(struct notifier_block *nb,
- unsigned long event, void *data)
-{
- struct device *dev = data;
-
- switch (event) {
- case BUS_NOTIFY_BIND_DRIVER:
- if (dev->of_node)
- exynos_read_domain_from_dt(dev);
-
- break;
-
- case BUS_NOTIFY_UNBOUND_DRIVER:
- exynos_remove_device_from_domain(dev);
-
- break;
- }
- return NOTIFY_DONE;
-}
-
-static struct notifier_block platform_nb = {
- .notifier_call = exynos_pm_notifier_call,
-};
-
static __init int exynos4_pm_init_power_domain(void)
{
struct platform_device *pdev;
@@ -202,7 +130,6 @@ static __init int exynos4_pm_init_power_domain(void)
pd->base = of_iomap(np, 0);
pd->pd.power_off = exynos_pd_power_off;
pd->pd.power_on = exynos_pd_power_on;
- pd->pd.of_node = np;
pd->oscclk = clk_get(dev, "oscclk");
if (IS_ERR(pd->oscclk))
@@ -228,15 +155,12 @@ static __init int exynos4_pm_i
Re: [PATCH v4 4/7] ARM: l2c: Add support for overriding prefetch settings
On 19/09/2014 at 17:39:32 +0100, Russell King - ARM Linux wrote : > On Fri, Sep 19, 2014 at 11:50:01AM +0200, Alexandre Belloni wrote: > > On 26/08/2014 at 16:17:57 +0200, Tomasz Figa wrote : > > > Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C > > > prefetch > > > settings configured in registers leading to crashes if L2C is enabled > > > without overriding them. This patch introduces bindings to enable > > > prefetch settings to be specified from DT and necessary support in the > > > driver. > > > > > > Signed-off-by: Tomasz Figa > > > > Tested-by: Alexandre Belloni > > > > It is working and useful on Atmel's sama5d4 were the bootloader is not > > configuring the L2C prefetch. However, I'm wondering whether we should > > add support for setting L310_PREFETCH_CTRL_DATA_PREFETCH and > > L310_PREFETCH_CTRL_INSTR_PREFETCH. I'm currently doing it by using > > ".l2c_aux_val= L310_AUX_CTRL_DATA_PREFETCH | > > L310_AUX_CTRL_INSTR_PREFETCH" (those are the same bits) but this has the > > disadvantage of displaying the "L2C: platform modifies aux control > > register:" twice. > > The L2C documentation, freely available from the ARM infocentre website, > has the answer to this for you. > > The two bits in the prefetch control register which control the data > and instruction prefetching are aliases of the aux control register. > If you set them to a value in one register, they are reflected in the > other. > > The reason for that is that once the L2 cache is enabled, writes to > the aux control register are no longer permitted, but it's safe to > enable and disable the prefetching with the cache already enabled. > This reason is even stated in the documentation. > Yeah, so my question still holds, should we have an other way to enable/disable I/D prefetch by adding two other DT bindings ? -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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 v10 5/6] rtc: max77686: Use ffs() to calculate tm_wday
Hello Joe,
On 09/19/2014 04:39 PM, Joe Perches wrote:
> On Fri, 2014-09-19 at 12:26 +0200, Javier Martinez Canillas wrote:
>> The function max77686_rtc_calculate_wday() is used to
>> calculate the day of the week to be filled in struct
>> rtc_time but that function only calculates the number
>> of bits shifted. So the ffs() function can be used to
>> find the first bit set instead of a special function.
>
> This isn't the same logic. Perhaps you want fls.
>
Right, the removed function has the same logic than fls() - 1 but the value
stored in data[RTC_WEEKDAY] is:
data[RTC_WEEKDAY] = 1 << tm->tm_wday;
so for this particular case, it doesn't matter since ffs() == fls() always.
>> diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
> []
>> -static inline int max77686_rtc_calculate_wday(u8 shifted)
>> -{
>> -int counter = -1;
>> -while (shifted) {
>> -shifted >>= 1;
>> -counter++;
>> -}
>> -return counter;
>> -}
>> -
>> static void max77686_rtc_data_to_tm(u8 *data, struct rtc_time *tm,
>> int rtc_24hr_mode)
>> {
>> @@ -93,7 +83,7 @@ static void max77686_rtc_data_to_tm(u8 *data, struct
>> rtc_time *tm,
>> tm->tm_hour += 12;
>> }
>>
>> -tm->tm_wday = max77686_rtc_calculate_wday(data[RTC_WEEKDAY] & 0x7f);
>> +tm->tm_wday = ffs(data[RTC_WEEKDAY] & 0x7f) - 1;
I did wonder which function to use and the question is when you want to know
the number of shifted bits, do you look for the first or the last bit set?
Of course is the same for powers of two but I did a naive search to have an
usage count:
$ git grep "shift = ffs(" | wc -l
39
$ git grep "shift = fls(" | wc -l
17
so it seems that ffs() is twice more popular than fls() for this case so I
decided to use ffs() but I don't have a strong opinion tbh.
Best regards,
Javier
--
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 v10 5/6] rtc: max77686: Use ffs() to calculate tm_wday
On Fri, 2014-09-19 at 21:27 +0200, Javier Martinez Canillas wrote: > Hello Joe, Hello Javier. > On 09/19/2014 04:39 PM, Joe Perches wrote: > > On Fri, 2014-09-19 at 12:26 +0200, Javier Martinez Canillas wrote: > >> The function max77686_rtc_calculate_wday() is used to > >> calculate the day of the week to be filled in struct > >> rtc_time but that function only calculates the number > >> of bits shifted. So the ffs() function can be used to > >> find the first bit set instead of a special function. > > > > This isn't the same logic. Perhaps you want fls. > > > > Right, the removed function has the same logic than fls() - 1 but the value > stored in data[RTC_WEEKDAY] is: > > data[RTC_WEEKDAY] = 1 << tm->tm_wday; > > so for this particular case, it doesn't matter since ffs() == fls() always. I didn't look that far. I just wanted to show that the logic wasn't the same. Perhaps you can specify that ffs==fls in the changelog. -- 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 v10 5/6] rtc: max77686: Use ffs() to calculate tm_wday
Hello Joe, On 09/19/2014 09:52 PM, Joe Perches wrote: > On Fri, 2014-09-19 at 21:27 +0200, Javier Martinez Canillas wrote: >> On 09/19/2014 04:39 PM, Joe Perches wrote: >> > On Fri, 2014-09-19 at 12:26 +0200, Javier Martinez Canillas wrote: >> >> The function max77686_rtc_calculate_wday() is used to >> >> calculate the day of the week to be filled in struct >> >> rtc_time but that function only calculates the number >> >> of bits shifted. So the ffs() function can be used to >> >> find the first bit set instead of a special function. >> > >> > This isn't the same logic. Perhaps you want fls. >> > >> >> Right, the removed function has the same logic than fls() - 1 but the value >> stored in data[RTC_WEEKDAY] is: >> >> data[RTC_WEEKDAY] = 1 << tm->tm_wday; >> >> so for this particular case, it doesn't matter since ffs() == fls() always. > > I didn't look that far. > > I just wanted to show that the logic wasn't the same. > No worries, thanks a lot for your feedback. Probably it would had been good to mention that in the commit message. > Perhaps you can specify that ffs==fls in the changelog. > I won't say I'm thrilled to do a whole re-spin of the series just to change that ;) Specially since I already did too many revisions and this series have been floating around for months but is up to Andrew to decide if is worth it. Best regards, Javier -- 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 v2] drm/exynos: switch to universal plane API
On Fri, Sep 19, 2014 at 6:58 AM, Andrzej Hajda wrote: > The patch replaces legacy functions > drm_plane_init() / drm_crtc_init() with > drm_universal_plane_init() and drm_crtc_init_with_planes(). > It allows to replace fake primary plane with the real one. > Additionally the patch leaves cleanup of crtcs to core, > this way planes and crtcs are cleaned in correct order. > > Signed-off-by: Andrzej Hajda Thanks Andrzej! With your patch the crashes I was seeing are gone. Daniel -- 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 v10 0/6] Add Maxim 77802 RTC support
Javier, On Fri, Sep 19, 2014 at 3:26 AM, Javier Martinez Canillas wrote: > Hello Andrew, > > This series add support for the Real Time clock present in > the Maxim 77802 Power Managment IC. The version number is > quite high because it previously was part of a bigger series > [0] that aimed to add support for all the devices in the > max77802 PMIC. But now that the max77802 dependencies were > already merged for 3.17, the series were split but I kept > the version numbering. > > While working on the max77802 rtc support a lot of feedback > was given and the issues pointed out also apply to a driver > for a similar PMIC RTC (max77686). So patches 01/06 to 05/06 > in the series are cleanups for the max77686 driver and patch > 06/06 adds the support for the max77802 RTC. > > This version address the issues pointed out on the previous > version [1] and changelog are present on each patch when is > applicable. > > The series were tested on an Exynos5250 Snow (max77686) and > Exynos5420 Peach Pit (max77802) machines and applies cleanly > to both 3.17-rc1 and today's linux-next (20140919). > > NOTE: The patches from the previous version [1] were already > present in the -mm tree [2] so I didn't know if I should had > sent this as a delta or as a new revision. I decided to do > the later but please let me know if you expected the former. My records show that Andrew has already accepted most of these. They may not show up in linuxnext yet, but that doesn't mean Andrew hasn't taken them (I think). > Doug Anderson (1): > rtc: max77686: Allow the max77686 rtc to wakeup the system http://ozlabs.org/~akpm/mmots/broken-out/rtc-max77686-allow-the-max77686-rtc-to-wakeup-the-system.patch > Javier Martinez Canillas (5): > rtc: max77686: Remove dead code for SMPL and WTSR. http://ozlabs.org/~akpm/mmots/broken-out/rtc-max77686-remove-dead-code-for-smpl-and-wtsr.patch > rtc: max77686: Fail to probe if no RTC regmap irqchip is set http://ozlabs.org/~akpm/mmots/broken-out/rtc-max77686-fail-to-probe-if-no-rtc-regmap-irqchip-is-set.patch > rtc: max77686: Remove unneded info log http://ozlabs.org/~akpm/mmots/broken-out/rtc-max77686-remove-unneded-info-log.patch > rtc: max77686: Use ffs() to calculate tm_wday This one hasn't been accepted... > rtc: Add driver for Maxim 77802 PMIC Real-Time-Clock http://ozlabs.org/~akpm/mmots/broken-out/rtc-add-driver-for-maxim-77802-pmic-real-time-clock.patch -Doug -- 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
