Re: Unable to boot mainline on snow chromebook since 3.15
Hello Doug, On 09/08/2014 06:36 AM, Doug Anderson wrote: One (ugly?) solution would be to add a feature to your bootloader to modify the device tree to mark regulators as always-on. Since the booloader gets to touch the device tree and the bootloader is involved in communicating into about SimpleFB, it kinda makes sense. I can't say I like to mark the regulators as always-on on the DT and that's why I copied the patch in the response instead of posting it as a proper patch but I think relying in the bootloaders to modify the DT is not better. IMHO U-boot should only modify the strictly necessary like the /chosen branch even though lately I've seen some attempts in the OMAP community to (ab)use U-Boot's fdt command to mangle the DT before passing to the kernel in order to support different Beagle Bone Black capes. 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 v9 0/6] Add Maxim 77802 clocks support
Hello Mike, On Mon, Aug 18, 2014 at 10:32 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: This series add support for the clocks present in the Maxim 77802 Power Managment IC. Previously, the series was part of a bigger one [0] that aimed to add support for all the devices in the max77802 PMIC. But now the Maxim 77802 PMIC dependencies were already merged for 3.17 so the series can be split and each driver can go through the relevant tree. This series was first posted for 3.17 and you acked the whole set but it missed 3.17 because had as a dependency some changes in the max77802 mfd driver. Those dependencies made for 3.17 and that's why I re-posted it for 3.18 about a month ago. Since we are in 3.17-rc4 already, I'm afraid that this series may miss 3.18 again, is there anything else you need from me to pick this series? It will obviously conflict with Tomeu's Per-user clock constraints series [0] so if you want I can rebase it on top of your clk-next-tomeu-kirkwood-v2 branch [1]. Thanks a lot and best regards, Javier [0]: https://lkml.org/lkml/2014/9/1/466 [1]: https://git.linaro.org/people/mike.turquette/linux.git/shortlog/refs/heads/clk-next-tomeu-kirkwood-v2 -- 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 v9 0/5] Add Maxim 77802 RTC support
Hello Alessandro, On Mon, Aug 18, 2014 at 10:34 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: This series add support for the Real Time clock present in the Maxim 77802 Power Managment IC. Previously, the series was part of a bigger one [0] that aimed to add support for all the devices in the max77802 PMIC. But now the max77802 dependencies were already merged for 3.17 so the series can be split and each driver can go through the relevant tree. 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/05 to 04/05 in the series are cleanups for the max77686 driver and patch 05/05 adds the support for the max77802 RTC. I kept the version numbering from the old series so this is version 9 although there were no changes on the max77802 rtc driver since v6 of the old series, only patches 03 and 04 were added on this version which are cleanups for the max77686 rtc. 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 (20140818). This series was first posted for 3.17 and you said that it was OK if it gets merged through the MFD tree but you didn't ack the set so it missed 3.17. The max77802 mfd driver dependency made it for 3.17 so that's why I re-posted it for 3.18 about a month ago but got no feedback so far... Since we are in 3.17-rc4 already, I'm afraid that this series may miss 3.18 again. Other people show their interest in the series since it has been reviewed and tested by many folks so it should be safe to merge them. Is there anything else you need from me to pick the series? Thanks a lot and 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 v9 3/5] rtc: max77686: Fail to probe if no RTC regmap irqchip is set
Hello Krzysztof, Sorry for the late response, I was on holidays and slowly catching up on email. On 08/28/2014 11:21 AM, Krzysztof Kozlowski wrote: On pon, 2014-08-18 at 10:34 +0200, Javier Martinez Canillas wrote: 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. The OOPS was possible only with Bartlomiej's patch because he changed the MFD driver probe function to skip IRQ setup on lack of interrupts. In current state the OOPS should not happen so mentioning OOPS in commit message may be misleading. Maybe just don't put the OOPS here? Anyway the patch looks good and a check for non-null regmap_irq_chip_data is still a valid precaution so: Yes I know but as you said the check for non-null is still a valid precaution (albeit maybe paranoid) just in case someone find that not having the IRQ hooked makes sense in a design and changes the mfd driver in the future. Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com Best regards, Krzysztof 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 1/3] ARM: dts: Add Peach Pit dts entry for Atmel touchpad
Hello Nick, On 09/02/2014 03:46 PM, Nick Dyer wrote: On 27/08/14 15:22, Javier Martinez Canillas wrote: If there was a BTN_NONE or KEY_UNUSED it would had been better but I think that making a distinction between these two cases (reserved pin vs GPIO available but not used) is useful. Maybe Nick can comment here. Yes, this is probably useful to document. However, I fear that it's not going to be obvious what the distinction is to someone who doesn't have the Atmel docs. Perhaps it would be clearer to just do something like: linux,gpio-keymap = KEY_RESERVED KEY_RESERVED KEY_RESERVED /* GPIO0 */ KEY_RESERVED /* GPIO1 */ KEY_RESERVED /* GPIO2 */ BTN_LEFT; /* GPIO3 */ If you omit any trailing KEY_RESERVED values it doesn't affect anything. I was also going to suggest that you put something like /* Atmel mXT224SL */ in your .dts file so it's clear what version of the maXTouch device you are configuring. Ok, I'll re-spin with those changes. Thanks a lot for your feedback. 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: Unable to boot mainline on snow chromebook since 3.15
On Sun, Sep 07, 2014 at 09:36:56PM -0700, Doug Anderson wrote: On Sun, Sep 7, 2014 at 8:52 AM, Tomasz Figa tomasz.f...@gmail.com wrote: So I believe we've got a process issue here. If you don't have normal support for display hardware, but you want to keep the display operational thanks to bootloader already initializing it, you should not add anything to the kernel which breaks it, until full support comes in. This means that respective regulators should be either always-on or not listed at all (I'd favor the former) and respective clocks either somehow enabled at boot-up or completely ignored, including all their parents capable of being gated. It seems slightly broken to hack the device tree in this way. I'll be the first to admit that I often list regulators as always-on during bringup when not everything is done, and I guess it's not that different. ...but given everything going on upstream (and people working on Suspend/Resume, DRM, etc) it seems like it might be a bit of a pain. ...but if that's what everyone agrees on, I won't disagree too strongly. One (ugly?) solution would be to add a feature to your bootloader to modify the device tree to mark regulators as always-on. Since the booloader gets to touch the device tree and the bootloader is involved in communicating into about SimpleFB, it kinda makes sense. That would seem to make sense, yes - we're apparently communicating this as a virtual device so we should make sure that virtual device has the resources it needs either directly or by reference to other devices so the driver can keep them on. Ideally we'd be doing this with fallback compatibles or something but this will probably work OK. I'd expect we're also going to run into the same problems with what people are currently doing with the SoC power domains, we also have code to power them off when they're idle, and this whole performance with adding hacks isn't going to be robust or scale - it's essentially just praying that nothing turns off the resources we need as far as I can tell. signature.asc Description: Digital signature
Re: [PATCH v2 6/7] mfd: cros_ec: Instantiate sub-devices from device tree
Hello Lee,
Sorry for the delay but had been on holidays last week.
On 09/04/2014 10:25 AM, Lee Jones wrote:
-static const struct mfd_cell cros_devs[] = {
-{
-.name = cros-ec-keyb,
-.id = 1,
-.of_compatible = google,cros-ec-keyb,
-},
-{
-.name = cros-ec-i2c-tunnel,
-.id = 2,
-.of_compatible = google,cros-ec-i2c-tunnel,
-},
-};
-
int cros_ec_register(struct cros_ec_device *ec_dev)
{
struct device *dev = ec_dev-dev;
+#ifdef CONFIG_OF
+struct device_node *node = dev-of_node;
+#endif
Drop the #ifdiffery.
I used the #ifdef guards because I remembered of_node being conditionally
build but I see that this is not longer true after commmit:
c9e358d driver-core: remove conditionals around devicetree pointers
So I'll remove it, thanks for the pointer.
int err = 0;
if (ec_dev-din_size) {
@@ -138,13 +129,19 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
mutex_init(ec_dev-lock);
-err = mfd_add_devices(dev, 0, cros_devs,
- ARRAY_SIZE(cros_devs),
- NULL, ec_dev-irq, NULL);
-if (err) {
-dev_err(dev, failed to add mfd devices\n);
-return err;
+#ifdef CONFIG_OF
And here.
Nod.
+/*
+ * Add sub-devices declared in the device tree. NOTE they should NOT be
+ * declared in cros_devs
+ */
Drop this comment. cros_devs no longer exists and we know what
of_platform_populate() does.
Ok.
+if (node) {
+err = of_platform_populate(node, NULL, NULL, dev);
+if (err) {
+dev_err(dev, fail to add %s\n, node-full_name);
That's not true. Just put Failed to register subordinate devices.
Ok.
+return err;
+}
}
+#endif
dev_info(dev, Chrome EC device registered\n);
Thanks a lot for the feedback and 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: Unable to boot mainline on snow chromebook since 3.15
Hi all, Sorry for the radio silence, the weekend happened :) On Fri, Sep 05, 2014 at 02:56:42PM +0100, Vivek Gautam wrote: On Fri, Sep 5, 2014 at 7:16 PM, Ajay kumar ajayn...@gmail.com wrote: I'd usually try to debug this a bit further, but without a console it's really painful to get anywhere. I've been working with 3.15, but now I'm having to backport patches when I want to test them, which is more effort than I can be bothered with. Is anybody else running mainline on this device and are these known/fixed problems? AFAIK, ARM chromebooks use DRM based display drivers and the required patches are still not merged: http://www.spinics.net/lists/dri-devel/msg66740.html Corresponding DT patches are also still not merged: http://www.spinics.net/lists/arm-kernel/msg358324.html http://www.spinics.net/lists/arm-kernel/msg358325.html There is a patch for configs as well: https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35828.html Try these patches(I hope they will apply directly on 3.17-rc3) and you should be able to use display on snow. We have pushed 3.17-rc3 kernel with above mentioned patches to github [1] Please use that, and in case you have some other requirements let us know. [1] https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-display I can give these a go but, as Marc has pointed out, things *used* to work and it's a shame that I need to start carrying patches after vanilla 3.15 was usable. Will -- 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: Unable to boot mainline on snow chromebook since 3.15
On Sun, Sep 07, 2014 at 05:19:03PM +0100, Tomasz Figa wrote: At least for next 3.17-rc I'd suggest fixing this up in respective clock driver and dropping the hack only after Exynos DRM patches are merged and confirmed working. Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux. Will -- 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 5/7] mfd: cros_ec: wait for completion of commands that return IN_PROGRESS
Hello Lee,
On 09/04/2014 10:34 AM, Lee Jones wrote:
On Mon, 25 Aug 2014, Javier Martinez Canillas wrote:
From: Andrew Bresticker abres...@chromium.org
When an EC command returns EC_RES_IN_PROGRESS, we need to query
the state of the EC until it indicates that it is no longer busy.
Do this in cros_ec_cmd_xfer() under the EC's mutex so that other
commands (e.g. keyboard, I2C passtru) aren't issued to the EC while
it is working on the in-progress command.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1:
- The *xfer() calls don't modify the passed cros_ec_command so there is
no need to populate it inside the for loop. Suggested by Lee Jones.
---
drivers/mfd/cros_ec.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index c53804a..cd0c93c 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -23,6 +23,10 @@
#include linux/mfd/core.h
#include linux/mfd/cros_ec.h
#include linux/mfd/cros_ec_commands.h
+#include linux/delay.h
+
+#define EC_COMMAND_RETRIES 50
+#define EC_RETRY_DELAY_MS 10
Where did these values come from?
These patches were taken from the ChromeOS 3.8 kernel so I don't really know
why these values were chosen. I'll let Andrew or one of the ChromiumOS folks
to answer this question.
int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg)
@@ -65,10 +69,38 @@ EXPORT_SYMBOL(cros_ec_check_result);
int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg)
{
-int ret;
+int ret, i;
+struct cros_ec_command status_msg;
+struct ec_response_get_comms_status status;
Please put these inside the if().
Ok.
mutex_lock(ec_dev-lock);
ret = ec_dev-cmd_xfer(ec_dev, msg);
+if (ret == -EAGAIN msg-result == EC_RES_IN_PROGRESS) {
Is there ever a time where (ret == -EAGAIN) but (msg-result !=
EC_RES_IN_PROGRESS) [note the !=]. And/or is there ever a time where
(msg-result == EC_RES_IN_PROGRESS) but (ret != -EAGAIN) [again, not
the !=].
Another way of explaining it. Can ret be anything other than -EAGAIN
when the result is EC_RES_IN_PROGRESS. And can the result be anything
other than EC_RES_IN_PROGRESS when ret is -EAGAIN?
For the first question, no. ret is always -EAGAIN when result is
EC_RES_IN_PROGRESS.
All the cros_ec transport drivers (cros_ec_{i2c,spi,lpc}) have the following
code block:
switch (msg-result) {
...
case EC_RES_IN_PROGRESS:
ret = -EAGAIN;
...
};
For the second question, yes AFAICT. Some transports transfer function return
-EAGAIN and that error is propagated. As an example i2c_transfer() returns
-EAGAIN if the struct i2c_adapter bus_lock mutex is tried to be acquired.
But after looking at all the cros_ec transport drivers it seems to be safe to
just check if result is EC_RES_IN_PROGRESS instead of checking also if ret is
-EAGAIN since (at least on all the current transport drivers) the former
implies the later.
+/*
+ * Query the EC's status until it's no longer busy or
+ * we encounter an error.
+ */
+status_msg.version = 0;
+status_msg.command = EC_CMD_GET_COMMS_STATUS;
+status_msg.outdata = NULL;
+status_msg.outsize = 0;
+status_msg.indata = (uint8_t *)status;
+status_msg.insize = sizeof(status);
+
+for (i = 0; i EC_COMMAND_RETRIES; i++) {
+msleep(EC_RETRY_DELAY_MS);
msleep() doesn't handle any time below 20ms well, use usleep() or even
better usleep_range() instead.
Ok.
+ret = ec_dev-cmd_xfer(ec_dev, status_msg);
+if (ret 0)
+break;
What does a ret of 0 mean?
When ret 0, it means the actual amount of data received in the transfer.
+msg-result = status_msg.result;
+if (status_msg.result != EC_RES_SUCCESS)
+break;
+if (!(status.flags EC_COMMS_STATUS_PROCESSING))
+break;
+}
+}
mutex_unlock(ec_dev-lock);
return ret;
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: Unable to boot mainline on snow chromebook since 3.15
Hello Will, On 09/08/2014 01:21 PM, Will Deacon wrote: On Sun, Sep 07, 2014 at 05:19:03PM +0100, Tomasz Figa wrote: At least for next 3.17-rc I'd suggest fixing this up in respective clock driver and dropping the hack only after Exynos DRM patches are merged and confirmed working. Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux. Agreed, I'm preparing a patch-set to prevent the kernel to disable both the clocks and regulators needed for the display, I'll try to post it today or tomorrow at worst. Will 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: Unable to boot mainline on snow chromebook since 3.15
On Mon, Sep 8, 2014 at 12:21 PM, Will Deacon will.dea...@arm.com wrote: On Sun, Sep 07, 2014 at 05:19:03PM +0100, Tomasz Figa wrote: At least for next 3.17-rc I'd suggest fixing this up in respective clock driver and dropping the hack only after Exynos DRM patches are merged and confirmed working. Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux. I would go further. The kernel behaviour has changed, and we have to deal with platforms that assume the old behaviour. That means either defaulting to leaving enabled regulators/clocks alone unless there is a flag in the DT saying they can be power managed, or black listing platforms that are known to depend on the regulator being on. Updating the device tree must not be required to get the kernel to boot, but it is valid to require a DT upgrade to get better performance (battery life) out of the platform. g. -- 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 0/5] Add max77802 support for Peach boards
Hello Kukjin, On Wed, Aug 20, 2014 at 1:19 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: This is a second version of the series that adds max77802 support for the Peach Pit and Pi boards. The series also have all the pending patches that were posted but depended on this support. I've picked all the patches I found and rebased them to be sure that they apply cleanly on top of linux-next. Also I've taken some DT snippets from the downstream Chrome OS 3.8 kernel DTS for devices that use one of these regulators as their input supply. Any comments on this series? 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 1/2] ARM: exynos_defconfig: Enable Control Groups support
Hello Andreas, On 08/27/2014 06:10 PM, Andreas Färber wrote: Am 27.08.2014 13:02, schrieb Javier Martinez Canillas: systemd needs control groups support to be enabled in the kernel so let's enable it by default since is quite likely that a user-space with systemd will be used. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 676c744..590abde 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -1,6 +1,7 @@ CONFIG_SYSVIPC=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y +CONFIG_CGROUPS=y CONFIG_BLK_DEV_INITRD=y CONFIG_KALLSYMS_ALL=y CONFIG_MODULES=y CONFIG_FHANDLE=y is also needed for systemd to get a serial console. multi_v7 has that already. That's a requirement for systemd = 209 AFAIK. I've systemd 208 on my debian jessie and it works without it. I agree that it should be included but I think it can be in a follow-up patch. Regards, Andreas 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: Unable to boot mainline on snow chromebook since 3.15
On Mon, Sep 08, 2014 at 12:55:29PM +0100, Javier Martinez Canillas wrote: On 09/08/2014 01:21 PM, Will Deacon wrote: On Sun, Sep 07, 2014 at 05:19:03PM +0100, Tomasz Figa wrote: At least for next 3.17-rc I'd suggest fixing this up in respective clock driver and dropping the hack only after Exynos DRM patches are merged and confirmed working. Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux. Agreed, I'm preparing a patch-set to prevent the kernel to disable both the clocks and regulators needed for the display, I'll try to post it today or tomorrow at worst. Thanks, Javier. Please CC me on the patch and I'll take it for a spin. Will -- 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 5/7] mfd: cros_ec: wait for completion of commands that return IN_PROGRESS
On Mon, 08 Sep 2014, Javier Martinez Canillas wrote:
On 09/04/2014 10:34 AM, Lee Jones wrote:
On Mon, 25 Aug 2014, Javier Martinez Canillas wrote:
From: Andrew Bresticker abres...@chromium.org
When an EC command returns EC_RES_IN_PROGRESS, we need to query
the state of the EC until it indicates that it is no longer busy.
Do this in cros_ec_cmd_xfer() under the EC's mutex so that other
commands (e.g. keyboard, I2C passtru) aren't issued to the EC while
it is working on the in-progress command.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1:
- The *xfer() calls don't modify the passed cros_ec_command so there is
no need to populate it inside the for loop. Suggested by Lee Jones.
---
drivers/mfd/cros_ec.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index c53804a..cd0c93c 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
[...]
mutex_lock(ec_dev-lock);
ret = ec_dev-cmd_xfer(ec_dev, msg);
+ if (ret == -EAGAIN msg-result == EC_RES_IN_PROGRESS) {
Is there ever a time where (ret == -EAGAIN) but (msg-result !=
EC_RES_IN_PROGRESS) [note the !=]. And/or is there ever a time where
(msg-result == EC_RES_IN_PROGRESS) but (ret != -EAGAIN) [again, not
the !=].
Another way of explaining it. Can ret be anything other than -EAGAIN
when the result is EC_RES_IN_PROGRESS. And can the result be anything
other than EC_RES_IN_PROGRESS when ret is -EAGAIN?
[...]
But after looking at all the cros_ec transport drivers it seems to be safe to
just check if result is EC_RES_IN_PROGRESS instead of checking also if ret is
-EAGAIN since (at least on all the current transport drivers) the former
implies the later.
That's exactly what I was getting at.
[...]
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: Don't we have phy_power_on() for that ? It looks like you could just as well do this from phy_power_on() ? No, unfortunately keeping these calibration settings in phy_power_on() doesn't help, since we need to do this after XHCI reset has happened. teach xHCI about PHYs ? sorry i couldn't understand you here. Aren't we trying to do the same with Heikki's patch about dwc3 : [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci and the 2nd patch in this series : [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds Is there something else that is expected ? right, use that to call phy_init() at the right time, then you need to add a new -calibrate() method which, likely, will only be used by you ;-) -- balbi signature.asc Description: Digital signature
Re: Unable to boot mainline on snow chromebook since 3.15
On Mon, Sep 08, 2014 at 01:20:11PM +0100, Grant Likely wrote: On Mon, Sep 8, 2014 at 12:21 PM, Will Deacon will.dea...@arm.com wrote: Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux. I would go further. The kernel behaviour has changed, and we have to deal with platforms that assume the old behaviour. That means either defaulting to leaving enabled regulators/clocks alone unless there is a flag in the DT saying they can be power managed, or black listing platforms that are known to depend on the regulator being on. For regulators there is essentially a flag in DT already - the regulators should not be described in DT if the OS isn't supposed to be managing them. Updating the device tree must not be required to get the kernel to boot, but it is valid to require a DT upgrade to get better performance (battery life) out of the platform. This has got to be a blacklist then, and it seems like we've got to fix simplefb to actually support managing the resources it's using. The current plan does not seem at all sensible - we're talking about adding hacks in every subsystem that provides resources and bodging DTs in order to work around simplefb. signature.asc Description: Digital signature
Re: Unable to boot mainline on snow chromebook since 3.15
Hello Will, On 09/08/2014 03:49 PM, Mark Brown wrote: On Mon, Sep 08, 2014 at 01:20:11PM +0100, Grant Likely wrote: On Mon, Sep 8, 2014 at 12:21 PM, Will Deacon will.dea...@arm.com wrote: Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux. I would go further. The kernel behaviour has changed, and we have to deal with platforms that assume the old behaviour. That means either defaulting to leaving enabled regulators/clocks alone unless there is a flag in the DT saying they can be power managed, or black listing platforms that are known to depend on the regulator being on. For regulators there is essentially a flag in DT already - the regulators should not be described in DT if the OS isn't supposed to be managing them. Updating the device tree must not be required to get the kernel to boot, but it is valid to require a DT upgrade to get better performance (battery life) out of the platform. This has got to be a blacklist then, and it seems like we've got to fix simplefb to actually support managing the resources it's using. The current plan does not seem at all sensible - we're talking about adding hacks in every subsystem that provides resources and bodging DTs in order to work around simplefb. Since many folks don't agree that hacking different subsystems is the way forward I'll hold the patches and don't post them. The sunxi thread [0] already shows how different people have strong opposite positions on the correct approach to handle this. For now you can just disable the tps65090 PMIC support by not enabling the CONFIG_REGULATOR_TPS65090 kconfig symbol on your kernel config. That will give you exactly the same behavior that before tps65090 support was added to the Snow DT on commit b16be76 (ARM: dts: add tps65090 power regulator for exynos5250-snow) which AFAIU was good enough for your workflow. Best regards, Javier [0]: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06623.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: S3C24XX: remove separate restart code
The restart-handler series from Guenter Roeck got accepted recently and
implements among other things also the restart handler in the samsung
watchdog driver and where applicable in the clock drivers. So there is
no need for having the restart callbacks in s3c24xx boards anymore.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/mach-s3c24xx/Kconfig | 2 --
arch/arm/mach-s3c24xx/common.c | 4
arch/arm/mach-s3c24xx/common.h | 5 -
.../mach-s3c24xx/include/mach/regs-s3c2443-clock.h | 2 --
arch/arm/mach-s3c24xx/mach-amlm5900.c | 1 -
arch/arm/mach-s3c24xx/mach-anubis.c| 1 -
arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 -
arch/arm/mach-s3c24xx/mach-bast.c | 1 -
arch/arm/mach-s3c24xx/mach-gta02.c | 1 -
arch/arm/mach-s3c24xx/mach-h1940.c | 1 -
arch/arm/mach-s3c24xx/mach-jive.c | 1 -
arch/arm/mach-s3c24xx/mach-mini2440.c | 1 -
arch/arm/mach-s3c24xx/mach-n30.c | 2 --
arch/arm/mach-s3c24xx/mach-nexcoder.c | 1 -
arch/arm/mach-s3c24xx/mach-osiris.c| 1 -
arch/arm/mach-s3c24xx/mach-otom.c | 1 -
arch/arm/mach-s3c24xx/mach-qt2410.c| 1 -
arch/arm/mach-s3c24xx/mach-rx1950.c| 1 -
arch/arm/mach-s3c24xx/mach-rx3715.c| 1 -
arch/arm/mach-s3c24xx/mach-s3c2416-dt.c| 1 -
arch/arm/mach-s3c24xx/mach-smdk2410.c | 1 -
arch/arm/mach-s3c24xx/mach-smdk2413.c | 3 ---
arch/arm/mach-s3c24xx/mach-smdk2416.c | 1 -
arch/arm/mach-s3c24xx/mach-smdk2440.c | 1 -
arch/arm/mach-s3c24xx/mach-smdk2443.c | 1 -
arch/arm/mach-s3c24xx/mach-tct_hammer.c| 1 -
arch/arm/mach-s3c24xx/mach-vr1000.c| 1 -
arch/arm/mach-s3c24xx/mach-vstms.c | 1 -
arch/arm/mach-s3c24xx/s3c2410.c| 13
arch/arm/mach-s3c24xx/s3c2412.c| 23 --
arch/arm/mach-s3c24xx/s3c2416.c| 8
arch/arm/mach-s3c24xx/s3c2443.c| 8
arch/arm/mach-s3c24xx/s3c244x.c| 12 ---
33 files changed, 104 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index ad5316a..9eb2229 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -32,7 +32,6 @@ config CPU_S3C2410
select S3C2410_DMA if S3C24XX_DMA
select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
select S3C2410_PM if PM
- select SAMSUNG_WDT_RESET
help
Support for S3C2410 and S3C2410A family from the S3C24XX line
of Samsung Mobile CPUs.
@@ -76,7 +75,6 @@ config CPU_S3C2442
config CPU_S3C244X
def_bool y
depends on CPU_S3C2440 || CPU_S3C2442
- select SAMSUNG_WDT_RESET
config CPU_S3C2443
bool SAMSUNG S3C2443
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 44fa95d..bf50328 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -51,7 +51,6 @@
#include plat/devs.h
#include plat/cpu-freq.h
#include plat/pwm-core.h
-#include plat/watchdog-reset.h
#include common.h
@@ -513,7 +512,6 @@ struct platform_device s3c2443_device_dma = {
void __init s3c2410_init_clocks(int xtal)
{
s3c2410_common_clk_init(NULL, xtal, 0, S3C24XX_VA_CLKPWR);
- samsung_wdt_reset_init(S3C24XX_VA_WATCHDOG);
}
#endif
@@ -535,7 +533,6 @@ void __init s3c2416_init_clocks(int xtal)
void __init s3c2440_init_clocks(int xtal)
{
s3c2410_common_clk_init(NULL, xtal, 1, S3C24XX_VA_CLKPWR);
- samsung_wdt_reset_init(S3C24XX_VA_WATCHDOG);
}
#endif
@@ -543,7 +540,6 @@ void __init s3c2440_init_clocks(int xtal)
void __init s3c2442_init_clocks(int xtal)
{
s3c2410_common_clk_init(NULL, xtal, 2, S3C24XX_VA_CLKPWR);
- samsung_wdt_reset_init(S3C24XX_VA_WATCHDOG);
}
#endif
diff --git a/arch/arm/mach-s3c24xx/common.h b/arch/arm/mach-s3c24xx/common.h
index ac3ff12..c7ac7e6 100644
--- a/arch/arm/mach-s3c24xx/common.h
+++ b/arch/arm/mach-s3c24xx/common.h
@@ -22,7 +22,6 @@ extern int s3c2410a_init(void);
extern void s3c2410_map_io(void);
extern void s3c2410_init_uarts(struct s3c2410_uartcfg *cfg, int no);
extern void s3c2410_init_clocks(int xtal);
-extern void s3c2410_restart(enum reboot_mode mode, const char *cmd);
extern void s3c2410_init_irq(void);
#else
#define s3c2410_init_clocks NULL
@@ -38,7 +37,6 @@ extern void s3c2412_map_io(void);
extern void s3c2412_init_uarts(struct s3c2410_uartcfg *cfg, int no);
extern void s3c2412_init_clocks(int xtal);
extern int s3c2412_baseclk_add(void);
-extern void s3c2412_restart(enum reboot_mode mode, const char *cmd);
extern void s3c2412_init_irq(void);
#else
Re: Unable to boot mainline on snow chromebook since 3.15
Javier, On Sun, Sep 7, 2014 at 11:09 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Doug, On 09/08/2014 06:36 AM, Doug Anderson wrote: One (ugly?) solution would be to add a feature to your bootloader to modify the device tree to mark regulators as always-on. Since the booloader gets to touch the device tree and the bootloader is involved in communicating into about SimpleFB, it kinda makes sense. I can't say I like to mark the regulators as always-on on the DT and that's why I copied the patch in the response instead of posting it as a proper patch but I think relying in the bootloaders to modify the DT is not better. IMHO U-boot should only modify the strictly necessary like the /chosen branch even though lately I've seen some attempts in the OMAP community to (ab)use U-Boot's fdt command to mangle the DT before passing to the kernel in order to support different Beagle Bone Black capes. So simple-framebuffer is added to the device tree here: https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c That's one of the two patches to build your own U-Boot for enabling simplefb. You'll notice that's not a super official thing. It's a DO NOT SUBMIT patch sitting in a gerrit code review server, so I wouldn't exactly call it a stable ABI that we can't break. It's not something shipping in real products and it's not even landed in a git tree (I suppose maybe someone somewhere landed it, but...). To me, that means that if someone is using that patch and it works for them, then that's great! If it stops working (possibly because it was making assumptions about the state of the kernel) then it should be fixed up. In this case, that patch really should be adding references to regulators (and possibly clocks) that are needed. Given that this patch is already reaching into the device tree to add the simple-framebuffer node, it doesn't seem unreasonable to say that it should be grabbing the proper references (or mark regulators as always-on). ...as always, though, remember that my opinion doesn't count for much. I also sympathize with the problems people are running into. :( -- 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: Unable to boot mainline on snow chromebook since 3.15
Grant, On Mon, Sep 8, 2014 at 5:20 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Mon, Sep 8, 2014 at 12:21 PM, Will Deacon will.dea...@arm.com wrote: On Sun, Sep 07, 2014 at 05:19:03PM +0100, Tomasz Figa wrote: At least for next 3.17-rc I'd suggest fixing this up in respective clock driver and dropping the hack only after Exynos DRM patches are merged and confirmed working. Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux. I would go further. The kernel behaviour has changed, and we have to deal with platforms that assume the old behaviour. That means either defaulting to leaving enabled regulators/clocks alone unless there is a flag in the DT saying they can be power managed, or black listing platforms that are known to depend on the regulator being on. Updating the device tree must not be required to get the kernel to boot, but it is valid to require a DT upgrade to get better performance (battery life) out of the platform. In this case people using SImple FB are not really using an officially sanctioned device tree. The simple-fb fragment is created on the fly via a DO NOT SUBMIT patch sitting on a code review server. It's not something that's shipped with real firmware nor is it something present in the kernel. See https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c as I mentioned above. Is this really a device tree that we need to guarantee backward compatibility with? -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
Re: Unable to boot mainline on snow chromebook since 3.15
On Mon, Sep 08, 2014 at 04:55:31PM +0100, Doug Anderson wrote: So simple-framebuffer is added to the device tree here: https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c That's one of the two patches to build your own U-Boot for enabling simplefb. You'll notice that's not a super official thing. It's a DO NOT SUBMIT patch sitting in a gerrit code review server, so I wouldn't exactly call it a stable ABI that we can't break. It's not something shipping in real products and it's not even landed in a git tree (I suppose maybe someone somewhere landed it, but...). I just took the uboot image linked to from the chromium.org page here: http://www.chromium.org/chromium-os/u-boot-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook#TOC-Getting-nv-U-Boot Will -- 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: Unable to boot mainline on snow chromebook since 3.15
Will, On Mon, Sep 8, 2014 at 9:07 AM, Will Deacon will.dea...@arm.com wrote: On Mon, Sep 08, 2014 at 04:55:31PM +0100, Doug Anderson wrote: So simple-framebuffer is added to the device tree here: https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c That's one of the two patches to build your own U-Boot for enabling simplefb. You'll notice that's not a super official thing. It's a DO NOT SUBMIT patch sitting in a gerrit code review server, so I wouldn't exactly call it a stable ABI that we can't break. It's not something shipping in real products and it's not even landed in a git tree (I suppose maybe someone somewhere landed it, but...). I just took the uboot image linked to from the chromium.org page here: http://www.chromium.org/chromium-os/u-boot-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook#TOC-Getting-nv-U-Boot Ah, OK. It's still using the DO NOT SUBMIT patchs, but I guess given that there is a binary built up there by a fairly official source... Hrmm. I think Olof is the one that built that. Perhaps he'd be willing to muck with that and see if he can grab the regulators? -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
Re: [PATCH v2 5/7] mfd: cros_ec: wait for completion of commands that return IN_PROGRESS
On Mon, Sep 8, 2014 at 4:39 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Lee, On 09/04/2014 10:34 AM, Lee Jones wrote: On Mon, 25 Aug 2014, Javier Martinez Canillas wrote: From: Andrew Bresticker abres...@chromium.org When an EC command returns EC_RES_IN_PROGRESS, we need to query the state of the EC until it indicates that it is no longer busy. Do this in cros_ec_cmd_xfer() under the EC's mutex so that other commands (e.g. keyboard, I2C passtru) aren't issued to the EC while it is working on the in-progress command. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Simon Glass s...@chromium.org Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v1: - The *xfer() calls don't modify the passed cros_ec_command so there is no need to populate it inside the for loop. Suggested by Lee Jones. --- drivers/mfd/cros_ec.c | 34 +- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c index c53804a..cd0c93c 100644 --- a/drivers/mfd/cros_ec.c +++ b/drivers/mfd/cros_ec.c @@ -23,6 +23,10 @@ #include linux/mfd/core.h #include linux/mfd/cros_ec.h #include linux/mfd/cros_ec_commands.h +#include linux/delay.h + +#define EC_COMMAND_RETRIES 50 +#define EC_RETRY_DELAY_MS 10 Where did these values come from? These patches were taken from the ChromeOS 3.8 kernel so I don't really know why these values were chosen. I'll let Andrew or one of the ChromiumOS folks to answer this question. These are the values flashrom used when retrying commands. -- 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: Unable to boot mainline on snow chromebook since 3.15
On Mon, Sep 8, 2014 at 4:58 PM, Doug Anderson diand...@chromium.org wrote: Grant, On Mon, Sep 8, 2014 at 5:20 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Mon, Sep 8, 2014 at 12:21 PM, Will Deacon will.dea...@arm.com wrote: On Sun, Sep 07, 2014 at 05:19:03PM +0100, Tomasz Figa wrote: At least for next 3.17-rc I'd suggest fixing this up in respective clock driver and dropping the hack only after Exynos DRM patches are merged and confirmed working. Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux. I would go further. The kernel behaviour has changed, and we have to deal with platforms that assume the old behaviour. That means either defaulting to leaving enabled regulators/clocks alone unless there is a flag in the DT saying they can be power managed, or black listing platforms that are known to depend on the regulator being on. Updating the device tree must not be required to get the kernel to boot, but it is valid to require a DT upgrade to get better performance (battery life) out of the platform. In this case people using SImple FB are not really using an officially sanctioned device tree. The simple-fb fragment is created on the fly via a DO NOT SUBMIT patch sitting on a code review server. It's not something that's shipped with real firmware nor is it something present in the kernel. See https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c as I mentioned above. Is this really a device tree that we need to guarantee backward compatibility with? Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has DO NOT SUBMIT in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression. g. -- 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 00/15] PM / Domains: Cleanups and remove superfluous APIs
On Friday, September 05, 2014 08:35:56 AM Kevin Hilman wrote: Ulf Hansson ulf.hans...@linaro.org writes: This patchset has a bit of a history and some parts of it has been posted earlier. http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262725.html The intent is to simplify code for the generic power domain and also some of the machine specific code that uses the generic power domain. Do note, there are dependencies through this patchset, especially related to the ARM SoC changes, thus they all need to be kept together. Reviewed-by: Kevin Hilman khil...@linaro.org My understanding is that this is for the whole series. Which I'm queuing up for 3.18, thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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 v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: Don't we have phy_power_on() for that ? It looks like you could just as well do this from phy_power_on() ? No, unfortunately keeping these calibration settings in phy_power_on() doesn't help, since we need to do this after XHCI reset has happened. teach xHCI about PHYs ? sorry i couldn't understand you here. Aren't we trying to do the same with Heikki's patch about dwc3 : [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci and the 2nd patch in this series : [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds Is there something else that is expected ? right, use that to call phy_init() at the right time, then you need to add a new -calibrate() method which, likely, will only be used by you ;-) so you mean, the xhci should itself call phy_init() at a time suitable, so that -calibrate() is not required at all ? i think you meant there - then you __do not__ need to add a new -calibrate() method which, likely, will only be used by you, is it ? -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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 5/7] arm64: dts: Add initial device tree support for EXYNOS7
Arnd Bergmann wrote:
On Thursday 04 September 2014 01:31:21 Kukjin Kim wrote:
This is the board specific file, so it seems ok.
I mean there are many espresso boards are having different exynos7
SoC. I mean exynos7-espresso cannot represent all of espresso boards.
Ah, I see, that makes sense.
We definitely need a top-level .dts file for each board that is different
in a nondiscoverable way then.
Agreed.
And one more, at this moment just using exynos7 would be nice to us then if
required, we could add any specific properties later.
If the mmc settings and possibly some other nodes (to be added later)
are common across them, those can be in a board specific .dtsi file.
Yes, right.
For the memory node, I would actually expect that to be filled by
the boot loader, so we could leave it out entirely. The same applies
to the command line: the parts that are in there at the moment (
console=ttySAC2,115200n8 root=/dev/ram0 ramdisk=16384 initrd=0x4200,16M)
clearly don't belong into a generic dts file and none of them should be
set that way.
Hmm...yeah we need to use proper boot-loader but I think kernel needs having
default memory property if boot loader doesn't have anything?
For the initial version, that would mean that the file comes down to having
as its only contents
/dts-v1/;
#include dt-bindings/gpio/gpio.h
#include exynos7123.dtsi
#include exynos7-espresso.dtsi // for the mmc nodes
/ {
model = Samsung ESPRESSO board based on EXYNOS7123;
compatible = samsung,espresso, samsung,exynos7123,
samsung,exynos7;
};
One more thing I just noticed is the GPL statement in the dts files.
Can we please change that to a permissive license in order to allow
including it in non-GPL boot loaders and operating systems?
Dual GPL+MIT or GPL+BSD would make most sense here.
I need to check about that with license guy in my team ;)
Naveen, I'll have a look at the patch again.
Thanks,
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 v2 5/7] 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 ch.nav...@samsung.com
Cc: Rob Herring r...@kernel.org
Cc: Catalin Marinas catalin.mari...@arm.com
---
arch/arm64/boot/dts/Makefile|1 +
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 31 +
arch/arm64/boot/dts/exynos/exynos7.dtsi | 168
+++
3 files changed, 200 insertions(+)
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/exynos/exynos7.dtsi
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
new file mode 100644
index 000..e593af55
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -0,0 +1,168 @@
+/*
+ * 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 dt-bindings/clock/exynos7-clk.h
+
+/ {
+ compatible = samsung,exynos7;
+ interrupt-parent = gic;
+ #address-cells = 2;
+ #address-cells = 1; ?
Hmm...I can't see any 64-bit address here.
+ #size-cells = 2;
+
[...]
+
+ soc: soc {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 0 0 0x1800;
+
+ chipid@1000 {
+ compatible = samsung,exynos4210-chipid;
+ reg = 0x1000 0x100;
+ };
Maybe this is not required? There is no check chipid in arm/arm64.
[...]
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff01,
+ 1 14 0xff01,
+ 1 11 0xff01,
+ 1 10 0xff01;
clock-frequency ?
[...]
- 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 v6 0/5] ARM: EXYNOS: cpuidle: fix AFTR mode on boards with secure firmware enabled
Bartlomiej Zolnierkiewicz wrote: Hi, Hi, This patch series adds support for AFTR idle mode on boards with secure firmware enabled and allows EXYNOS cpuidle driver usage on Exynos4x12 SoCs. It has been tested on Trats2 board (using Exynos4412 SoC with secure firmware enabled) on which AFTR mode reduces power consumption by ~12% Nice. when EXYNOS cpuidle driver is enabled (in both cases the default exynos_defconfig config is used and CPU1-3 are offlined). Currently Exynos4412 SoC support is limited to Trats2 board. Depends on: - next-20140904 branch of linux-next kernel tree - irqchip: Properly fetch the per cpu offset patch (https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg716674.html) - [PATCH v3 0/5] Firmware-assisted suspend/resume of Exynos SoCs (https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35921.html) OK this series looks good to me, I will take this series once above patches are landed. Thanks, Kukjin Changes since v5: - rebased on top of next-20140904 + irqchip: Properly fetch the per cpu offset patch (https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg716674.html) [PATCH v3 0/5] Firmware-assisted suspend/resume of Exynos SoCs (https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35921.html) - limit Exynos4412 SoC support to Trats2 board for now Changes since v4: - rebased on top of next-20140804 + [PATCH v5][next-20140804] ARM: EXYNOS: Fix suspend/resume sequences (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35262.html) [PATCH v2 0/2] Firmware-assisted suspend/resume of Exynos SoCs (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34282.html) - call exynos_save_cp15() only on A9 type core (this is needed for the future Exynos3250 SoC support) Changes since v3: - rebased on top of next-20140804 + [PATCH v4][next-20140804] ARM: EXYNOS: Fix suspend/resume sequences (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35192.html) [PATCH v2 0/2] Firmware-assisted suspend/resume of Exynos SoCs (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34282.html) - (re-)added patch fixing S5P_CENTRAL_SEQ_OPTION register setup Changes since v2: - rebased on top of next-20140708 + [PATCH 5/6] ARM: EXYNOS: Fix suspend/resume sequencies (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32809.html) [with rejects fixed] [PATCH 6/6] ARM: EXYNOS: Register cpuidle device only on Exynos4210 and 5250 (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32808.html) [PATCH 0/2] Firmware-assisted suspend/resume of Exynos SoCs (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32991.html) [with rejects fixed in patch #2] - addressed review comments from Tomasz Figa and Daniel Lezcano Changes since v1: - synced against next-20140602 - added missing Acked-by-s Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (5): ARM: EXYNOS: PM: replace EXYNOS_BOOT_VECTOR_* macros by static inlines ARM: EXYNOS: add AFTR mode support to firmware do_idle method ARM: EXYNOS: cpuidle: add secure firmware support to AFTR mode code ARM: EXYNOS: PM: fix register setup for AFTR mode code ARM: EXYNOS: cpuidle: allow driver usage on Exynos4x12 SoCs arch/arm/include/asm/firmware.h | 2 +- arch/arm/mach-exynos/common.h | 5 arch/arm/mach-exynos/exynos.c | 5 +++- arch/arm/mach-exynos/firmware.c | 34 --- arch/arm/mach-exynos/pm.c | 60 - 5 files changed, 71 insertions(+), 35 deletions(-) -- 1.8.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 RESEND 1/3] ARM: EXYNOS: Move code from hotplug.c to platsmp.c
Krzysztof Kozlowski wrote: Cleanup a little the SMP/hotplug code for Exynos by: 1. Moving completely all functions from hotplug.c into the platsmp.c; 2. Deleting the hotplug.c file. After recent cleanups (e.g. 75ad2ab28f0f ARM: EXYNOS: use v7_exit_coherency_flush macro for cache disabling) there was only CPU power down related code in hotplug.c file. Rationale behind the code movement and benefits: 1. The file platsmp.c is the only user of code located in hotplug.c. Keeping code in hotplug.c required declaring exynos_cpu_die() in common.h. Such dependencies and mentioned exynos_cpu_die() declaration can be removed. 2. In next patches exynos_set_delayed_reset_assertion() will be introduced. This function will be called by: - cpu_leave_power (hotplug.c), - platform_do_lowpower (hotplug.c), - exynos_boot_secondary (platsmp.c). Merging hotplug.c into platsmp.c leads to simpler and cleaner code with less dependencies between files. The commit only moves code around with one additional observable change: the hotplug.c was compiled with custom CFLAGS (-march=armv7-a). These CFLAGS are not necessary any more. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- Changes since v4: 1. Rebase on linux-next-20140804. 2. Add Reviewed-by Tomasz Figa. --- arch/arm/mach-exynos/Makefile | 3 -- arch/arm/mach-exynos/common.h | 2 - arch/arm/mach-exynos/hotplug.c | 91 -- arch/arm/mach-exynos/platsmp.c | 74 ++ 4 files changed, 74 insertions(+), 96 deletions(-) delete mode 100644 arch/arm/mach-exynos/hotplug.c [...] OK, I will take this series but I'm not sure what conflicts will be happened with other pm related patches. If anything, I'll let you know ;) Thanks, 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 v2 0/5] Add max77802 support for Peach boards
Javier Martinez Canillas wrote: Hello Kukjin, Hi, On Wed, Aug 20, 2014 at 1:19 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: This is a second version of the series that adds max77802 support for the Peach Pit and Pi boards. The series also have all the pending patches that were posted but depended on this support. I've picked all the patches I found and rebased them to be sure that they apply cleanly on top of linux-next. Also I've taken some DT snippets from the downstream Chrome OS 3.8 kernel DTS for devices that use one of these regulators as their input supply. Any comments on this series? Looks good to me but I just wanted to get ack from chrome guy, Doug? But since Naveen tested, it should be fine I think. I'll take the series. Thanks, 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: [RESEND PATCH v4 2/2] ARM: EXYNOS: Refactor the pm code to use DT based lookup
Hi Kukjin, On Wed, Sep 3, 2014 at 7:10 PM, Kukjin Kim kgene@samsung.com wrote: Vikas Sajjan wrote: Hi, Hi, Sorry for late response... On Tue, Aug 19, 2014 at 3:05 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Hi, On Tuesday, August 19, 2014 01:26:49 PM Vikas Sajjan wrote: Hi Kukjin, On Tue, Aug 19, 2014 at 12:22 PM, Vikas Sajjan vikas.saj...@samsung.com wrote: Refactoring the pm.c to avoid using soc_is_exynos checks, instead use the DT based lookup. While at it, consolidate the common code across SoCs and create static helper functions. Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com Can you pick this series... I think that my PM_SLEEP=n build fixes should go in before this cleanup series: Its better for Kukjin to decide which series he wants to pick first. Hmm...I need to have a look at the Bart's fix then I'll let you know. Maybe tomorrow morning ;) PING... http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35430.html - 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 -- 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
