Re: asix: Don't reset PHY on if_up for ASIX 88772 breaks net on arndale platform
On Wed, Nov 05, 2014 at 03:02:58PM +, Charles Keepax wrote: On Wed, Nov 05, 2014 at 01:04:37PM +0100, Stam, Michel [FINT] wrote: Hello Charles, After looking around I found the reset value for the 8772 chip, which seems to be 0x1E1 (ANAR register). This equates to (according to include/uapi/linux/mii.h) ADVERTISE_ALL | ADVERTISE_CSMA. The register only seems to become 0 if the software reset fails. Odd it definitely reads back as zero on Arndale. I am guessing that the root of the problem here is that for some reason Arndale POR of the ethernet is pants and it needs a full software reset before it will work and the patch removes the full reset callback. The asix on arndale comes semi-configured from u-boot, which I guess is not the state kernel expects it to come in. At least in my case where I use tftp from u-boot to load my kernel. So probably the full reset is needed here to make the asix chip come to a truly pristine state. The commit that Michel partially reverted (by returning to use ax88772_link_reset instead of ax88772_reset), indicates that a strong reset is needed for suspend/resume as well: commit 4ad1438f025ed8d1e4e95a796ca7f0ad5a22c378 Author: Grant Grundler grund...@chromium.org Date: Tue Oct 4 09:55:16 2011 + NET: fix phy init for AX88772 USB ethernet Fix phy initialization for AX88772 (USB 2.0 100BT). Failure was occasionally DHCP wouldn't work after reboot or suspend/resume cycle. Unfortunately, this is exactly what I get when the patch is applied; asix 1-2:1.0 eth1: Failed to send software reset: ffb5 asix 1-2:1.0 eth1: link reset failed (-75) usbnet usb-:00:1d.0-2, ASIX AX88772 USB 2.0 Ethernet asix 1-2:1.0 eth1: Failed to send software reset: ffb5 asix 1-2:1.0 eth1: link reset failed (-75) usbnet usb-:00:1d.0-2, ASIX AX88772 USB 2.0 Ethernet Ok so I am guessing you have a value in the register which is neither the reset value or 0 and this causing problems later in the reset/on the next reset. I do find the naming confusing in the error message there as it says link reset failed but the link_reset callback can't fail in the driver and I modified the reset callback. But I guess that is just oddities of the network stack I am not familiar with. The other thing that feels odd is (and again apologies as I know next to nothing about the networking stack) how come it is unexpected that the reset callback destroys the state of the device. Naively I would have expected that a reset callback would reset the device back to its default state. Here we seem to be trying to avoid that happening. Indeed, it would seems some tracing would be neede to figure out in which order the .reset and .link_reset callbacks are being called. -- 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
[BUG] blocked task after exynos_drm_init
Hi,
On last next (next-20141104, next-20141105) booting locks after
initializing Exynos DRM (Trats2 board):
[2.028283] [drm] Initialized drm 1.1.0 20060810
[ 240.505795] INFO: task swapper/0:1 blocked for more than 120 seconds.
[ 240.510825] Not tainted 3.18.0-rc3-next-20141105 #794
[ 240.516418] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this
message.
[ 240.524173] swapper/0 D c052534c 0 1 0 0x
[ 240.530527] [c052534c] (__schedule) from [c0525b34]
(schedule_preempt_disabled+0x14/0x20)
[ 240.539030] [c0525b34] (schedule_preempt_disabled) from [c0526d44]
(mutex_lock_nested+0x1c4/0x464)
[ 240.548320] [c0526d44] (mutex_lock_nested) from [c02be908]
(__driver_attach+0x48/0x98)
[ 240.556562] [c02be908] (__driver_attach) from [c02bcc00]
(bus_for_each_dev+0x54/0x88)
[ 240.564717] [c02bcc00] (bus_for_each_dev) from [c02bdce0]
(bus_add_driver+0xe4/0x200)
[ 240.572876] [c02bdce0] (bus_add_driver) from [c02bef94]
(driver_register+0x78/0xf4)
[ 240.580864] [c02bef94] (driver_register) from [c029e99c]
(exynos_drm_platform_probe+0x34/0x234)
[ 240.589890] [c029e99c] (exynos_drm_platform_probe) from [c02bfcf0]
(platform_drv_probe+0x48/0xa4)
[ 240.599090] [c02bfcf0] (platform_drv_probe) from [c02be680]
(driver_probe_device+0x13c/0x37c)
[ 240.607940] [c02be680] (driver_probe_device) from [c02be954]
(__driver_attach+0x94/0x98)
[ 240.616360] [c02be954] (__driver_attach) from [c02bcc00]
(bus_for_each_dev+0x54/0x88)
[ 240.624517] [c02bcc00] (bus_for_each_dev) from [c02bdce0]
(bus_add_driver+0xe4/0x200)
[ 240.632679] [c02bdce0] (bus_add_driver) from [c02bef94]
(driver_register+0x78/0xf4)
[ 240.640667] [c02bef94] (driver_register) from [c029e938]
(exynos_drm_init+0x70/0xa0)
[ 240.648739] [c029e938] (exynos_drm_init) from [c00089b0]
(do_one_initcall+0xac/0x1f0)
[ 240.656914] [c00089b0] (do_one_initcall) from [c074bd90]
(kernel_init_freeable+0x10c/0x1d8)
[ 240.665591] [c074bd90] (kernel_init_freeable) from [c051eabc]
(kernel_init+0x8/0xec)
[ 240.673661] [c051eabc] (kernel_init) from [c000f268]
(ret_from_fork+0x14/0x2c)
[ 240.681196] 3 locks held by swapper/0/1:
[ 240.685091] #0: (dev-mutex){..}, at: [c02be908]
__driver_attach+0x48/0x98
[ 240.692732] #1: (dev-mutex){..}, at: [c02be918]
__driver_attach+0x58/0x98
[ 240.700367] #2: (dev-mutex){..}, at: [c02be908]
__driver_attach+0x48/0x98
Full dmesg and config attached.
Best regards,
Krzysztof
[0.00] Booting Linux on physical CPU 0xa00
[0.00] Linux version 3.18.0-rc3-next-20141105 (k.kozlowski@AMDC1943)
(gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #794 SMP PREEMPT Thu Nov 6
09:52:53 CET 2014
[0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine model: Samsung Trats 2 based on Exynos4412
[0.00] cma: Reserved 64 MiB at 0x7bc0
[0.00] Memory policy: Data cache writealloc
[0.00] Running under secure firmware.
[0.00] PERCPU: Embedded 10 pages/cpu @eee77000 s8448 r8192 d24320 u40960
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 260178
[0.00] Kernel command line: root=/dev/mmcblk0p5 rw rootfstype=ext4
rootwait console=ttySAC2,115200n8 fbmem=24M@0x5200 normal lcd=s6e8ax0
pmic_info=3 resume=179:3 csa=/dev/mmcblk0p1 bootloader_log=1076@0x43908010
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 955100K/1047552K available (5443K kernel code, 378K
rwdata, 1992K rodata, 308K init, 8171K bss, 26916K reserved, 65536K
cma-reserved, 203776K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xffc0 - 0xffe0 (2048 kB)
[0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB)
[0.00] lowmem : 0xc000 - 0xef80 ( 760 MB)
[0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
[0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB)
[0.00] .text : 0xc0008000 - 0xc074af44 (7436 kB)
[0.00] .init : 0xc074b000 - 0xc0798000 ( 308 kB)
[0.00] .data : 0xc0798000 - 0xc07f6b88 ( 379 kB)
[0.00].bss : 0xc07f6b88 - 0xc0ff17cc (8172 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00] RCU lockdep checking is enabled.
[0.00] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[0.00] Running RCU self tests
[0.00] NR_IRQS:16 nr_irqs:16 16
[
Re: [PATCH] drm/panel: simple: Add AUO B116XW03 panel support
On Mon, Sep 01, 2014 at 03:40:02PM +0530, Ajay Kumar wrote: The AUO B116XW03 is a 11.6 HD TFT LCD panel connecting to a LVDS interface and with an integrated LED backlight unit. This panel is used on the Samsung Chromebook(XE303C12). Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- .../devicetree/bindings/panel/auo,b116xw03.txt |7 ++ drivers/gpu/drm/panel/panel-simple.c | 25 2 files changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/auo,b116xw03.txt Applied after adding the missing .bpc field in the panel descriptor. I set it to 6 according to the datasheet. Thierry pgpExRCIQ_YtS.pgp Description: PGP signature
[PATCH] spi: s3c64xx: add support for exynos7 SPI controller
Exynos7 SPI controller supports only the auto Selection of
CS toggle mode and Exynos7 SoC includes six SPI controllers.
Add support for these changes in Exynos7 SPI controller driver.
Signed-off-by: Padmavathi Venna padm...@samsung.com
---
.../devicetree/bindings/spi/spi-samsung.txt|2 +-
drivers/spi/Kconfig|2 +-
drivers/spi/spi-s3c64xx.c | 32 ---
3 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt
b/Documentation/devicetree/bindings/spi/spi-samsung.txt
index 1e8a857..6dbdeb3 100644
--- a/Documentation/devicetree/bindings/spi/spi-samsung.txt
+++ b/Documentation/devicetree/bindings/spi/spi-samsung.txt
@@ -9,7 +9,7 @@ Required SoC Specific Properties:
- samsung,s3c2443-spi: for s3c2443, s3c2416 and s3c2450 platforms
- samsung,s3c6410-spi: for s3c6410 platforms
- samsung,s5pv210-spi: for s5pv210 and s5pc110 platforms
-- samsung,exynos4210-spi: for exynos4 and exynos5 platforms
+- samsung,exynos7-spi: for exynos7 platforms
- reg: physical base address of the controller and length of memory mapped
region.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 84e7c9e..de2d33d 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -444,7 +444,7 @@ config SPI_S3C24XX_FIQ
config SPI_S3C64XX
tristate Samsung S3C64XX series type SPI
- depends on PLAT_SAMSUNG
+ depends on (PLAT_SAMSUNG || ARCH_EXYNOS)
select S3C64XX_PL080 if ARCH_S3C64XX
help
SPI driver for Samsung S3C64XX and newer SoCs.
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 480133e..59e07cf 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -33,8 +33,9 @@
#include linux/platform_data/spi-s3c64xx.h
-#define MAX_SPI_PORTS 3
+#define MAX_SPI_PORTS 6
#define S3C64XX_SPI_QUIRK_POLL (1 0)
+#define S3C64XX_SPI_QUIRK_CS_AUTO (1 1)
/* Registers and bit-fields */
@@ -78,6 +79,7 @@
#define S3C64XX_SPI_SLAVE_AUTO (11)
#define S3C64XX_SPI_SLAVE_SIG_INACT(10)
+#define S3C64XX_SPI_SLAVE_NSC_CNT_2(24)
#define S3C64XX_SPI_INT_TRAILING_EN(16)
#define S3C64XX_SPI_INT_RX_OVERRUN_EN (15)
@@ -717,7 +719,12 @@ static int s3c64xx_spi_transfer_one(struct spi_master
*master,
enable_datapath(sdd, spi, xfer, use_dma);
/* Start the signals */
- writel(0, sdd-regs + S3C64XX_SPI_SLAVE_SEL);
+ if (!(sdd-port_conf-quirks S3C64XX_SPI_QUIRK_CS_AUTO))
+ writel(0, sdd-regs + S3C64XX_SPI_SLAVE_SEL);
+ else
+ writel(readl(sdd-regs + S3C64XX_SPI_SLAVE_SEL)
+ | S3C64XX_SPI_SLAVE_AUTO | S3C64XX_SPI_SLAVE_NSC_CNT_2,
+ sdd-regs + S3C64XX_SPI_SLAVE_SEL);
spin_unlock_irqrestore(sdd-lock, flags);
@@ -866,13 +873,15 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
}
pm_runtime_put(sdd-pdev-dev);
- writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd-regs + S3C64XX_SPI_SLAVE_SEL);
+ if (!(sdd-port_conf-quirks S3C64XX_SPI_QUIRK_CS_AUTO))
+ writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd-regs +
S3C64XX_SPI_SLAVE_SEL);
return 0;
setup_exit:
pm_runtime_put(sdd-pdev-dev);
/* setup() returns with device de-selected */
- writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd-regs + S3C64XX_SPI_SLAVE_SEL);
+ if (!(sdd-port_conf-quirks S3C64XX_SPI_QUIRK_CS_AUTO))
+ writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd-regs +
S3C64XX_SPI_SLAVE_SEL);
if (gpio_is_valid(spi-cs_gpio))
gpio_free(spi-cs_gpio);
@@ -946,7 +955,8 @@ static void s3c64xx_spi_hwinit(struct
s3c64xx_spi_driver_data *sdd, int channel)
sdd-cur_speed = 0;
- writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd-regs + S3C64XX_SPI_SLAVE_SEL);
+ if (!(sdd-port_conf-quirks S3C64XX_SPI_QUIRK_CS_AUTO))
+ writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd-regs +
S3C64XX_SPI_SLAVE_SEL);
/* Disable Interrupts - we use Polling if not DMA mode */
writel(0, regs + S3C64XX_SPI_INT_EN);
@@ -1341,6 +1351,15 @@ static struct s3c64xx_spi_port_config
exynos5440_spi_port_config = {
.quirks = S3C64XX_SPI_QUIRK_POLL,
};
+static struct s3c64xx_spi_port_config exynos7_spi_port_config = {
+ .fifo_lvl_mask = { 0x1ff, 0x7F, 0x7F, 0x7F, 0x7F, 0x1ff},
+ .rx_lvl_offset = 15,
+ .tx_st_done = 25,
+ .high_speed = true,
+ .clk_from_cmu = true,
+ .quirks = S3C64XX_SPI_QUIRK_CS_AUTO,
+};
+
static struct platform_device_id s3c64xx_spi_driver_ids[] = {
{
.name = s3c2443-spi,
@@ -1374,6 +1393,9 @@ static const struct of_device_id s3c64xx_spi_dt_match[] =
{
{ .compatible = samsung,exynos5440-spi,
Re: [PATCH] PM / Domains: Change prototype for the -attach_dev() callback
On 6 November 2014 00:11, Kevin Hilman khil...@kernel.org wrote:
Rafael J. Wysocki r...@rjwysocki.net writes:
On Wednesday, November 05, 2014 02:43:31 PM Kevin Hilman wrote:
Dmitry Torokhov dmitry.torok...@gmail.com writes:
On Thu, Oct 30, 2014 at 01:38:30PM -0700, Kevin Hilman wrote:
Rafael J. Wysocki r...@rjwysocki.net writes:
On Thursday, October 30, 2014 01:02:49 PM Ulf Hansson wrote:
Convert the prototype to return and int. This is just an initial step,
needed to support error handling.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Kevin Hilman khil...@linaro.org
This patch is intended as fix for 3.18 rc[n]. Why?
There are other SOC specific patches around that adds genpd support
and which
implements the -attach_dev() callback. To prevent having an atomic
patch
during the next release cycle, let's change the prototype now instead.
Further patches will add the actual error handling in genpd and these
can then
be reviewed and tested thoroughly.
So we have no users of -attach_dev at the moment, right?
Not in mainline, but there are a couple getting ready to hit -next, so
we wanted to fix this before they arrive so that adding the error
handling will be easier.
BTW, while we are at it, can we also pass the domain itself to
attach_dev() and detach_dev()? If anything it helps with debugging (you
can print domain name from the callbacks).
Agreed, and it makes it match the other callbacks (power_off, power_on)
which currently take struct generic_pm_domain *domain.
Updated version of $SUBJECT patch below.
The subject and changelog need to be updated too IMO.
Right. Here you go.
Kevin
Thanks for helping out Kevin!
Kind regards
Uffe
- 8 --
From c18a6bf3121979c4102ba4f7edb3ac41e3921fc6 Mon Sep 17 00:00:00 2001
From: Ulf Hansson ulf.hans...@linaro.org
Date: Thu, 30 Oct 2014 13:02:49 +0100
Subject: [PATCH] PM / Domains: Change prototype for the attach and detach
callbacks
Convert the prototypes to return an int in order to support error
handling in these callbacks.
Also, as suggested by Dmitry Torokhov, pass the domain pointer for use
inside the callbacks, and so that they match the existing
power_on/power_off callbacks which currently take the domain pointer.
Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com
[khilman: added domain as parameter to callbacks, as suggested by Dmitry]
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Signed-off-by: Kevin Hilman khil...@linaro.org
---
drivers/base/power/domain.c | 4 ++--
include/linux/pm_domain.h | 6 --
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 40bc2f4072cc..b520687046d4 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1437,7 +1437,7 @@ int __pm_genpd_add_device(struct generic_pm_domain
*genpd, struct device *dev,
spin_unlock_irq(dev-power.lock);
if (genpd-attach_dev)
- genpd-attach_dev(dev);
+ genpd-attach_dev(genpd, dev);
mutex_lock(gpd_data-lock);
gpd_data-base.dev = dev;
@@ -1499,7 +1499,7 @@ int pm_genpd_remove_device(struct generic_pm_domain
*genpd,
genpd-max_off_time_changed = true;
if (genpd-detach_dev)
- genpd-detach_dev(dev);
+ genpd-detach_dev(genpd, dev);
spin_lock_irq(dev-power.lock);
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 73e938b7e937..b3ed7766a291 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -72,8 +72,10 @@ struct generic_pm_domain {
bool max_off_time_changed;
bool cached_power_down_ok;
struct gpd_cpuidle_data *cpuidle_data;
- void (*attach_dev)(struct device *dev);
- void (*detach_dev)(struct device *dev);
+ int (*attach_dev)(struct generic_pm_domain *domain,
+ struct device *dev);
+ void (*detach_dev)(struct generic_pm_domain *domain,
+ struct device *dev);
};
static inline struct generic_pm_domain *pd_to_genpd(struct dev_pm_domain *pd)
--
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: asix: Don't reset PHY on if_up for ASIX 88772 breaks net on arndale platform
On Thu, Nov 06, 2014 at 11:06:51AM +0200, Riku Voipio wrote: On Wed, Nov 05, 2014 at 03:02:58PM +, Charles Keepax wrote: On Wed, Nov 05, 2014 at 01:04:37PM +0100, Stam, Michel [FINT] wrote: Hello Charles, After looking around I found the reset value for the 8772 chip, which seems to be 0x1E1 (ANAR register). This equates to (according to include/uapi/linux/mii.h) ADVERTISE_ALL | ADVERTISE_CSMA. The register only seems to become 0 if the software reset fails. Odd it definitely reads back as zero on Arndale. I am guessing that the root of the problem here is that for some reason Arndale POR of the ethernet is pants and it needs a full software reset before it will work and the patch removes the full reset callback. The asix on arndale comes semi-configured from u-boot, which I guess is not the state kernel expects it to come in. At least in my case where I use tftp from u-boot to load my kernel. So probably the full reset is needed here to make the asix chip come to a truly pristine state. The commit that Michel partially reverted (by returning to use ax88772_link_reset instead of ax88772_reset), indicates that a strong reset is needed for suspend/resume as well: Ok I think I have cracked this one. I am pretty sure you are right that the USB comes to us in a strange state and needs a full reset, but that only needs to happen once when the driver is bound in. So there is some code in ax88772_bind that appears to try to reset the device but does a lot less than ax88772_reset and I think that must be the problem. Applying the following on top of the patch we have been debating I think will make everything work for all of us: --- a/drivers/net/usb/asix_devices.c +++ b/drivers/net/usb/asix_devices.c @@ -465,19 +465,7 @@ static int ax88772_bind(struct usbnet *dev, struct usb_interface *in return ret; } - ret = asix_sw_reset(dev, AX_SWRESET_IPPD | AX_SWRESET_PRL); - if (ret 0) - return ret; - - msleep(150); - - ret = asix_sw_reset(dev, AX_SWRESET_CLEAR); - if (ret 0) - return ret; - - msleep(150); - - ret = asix_sw_reset(dev, embd_phy ? AX_SWRESET_IPRL : AX_SWRESET_PRTE); + ax88772_reset(dev); If you guys could test that and let me know how you get on I will send in a proper patch if it looks good. Thanks, Charles -- 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] spi: s3c64xx: add support for exynos7 SPI controller
On Thu, Nov 06, 2014 at 03:21:49PM +0530, Padmavathi Venna wrote: Exynos7 SPI controller supports only the auto Selection of CS toggle mode and Exynos7 SoC includes six SPI controllers. Add support for these changes in Exynos7 SPI controller driver. Could you give a bit more detail on what the auto selection of CS toggle mode is - in the diff it looks like it's not an existing mode. I'm a bit worried that it's not going to function well with devices that send more than one transfer per message. Signed-off-by: Padmavathi Venna padm...@samsung.com It's better if your signoff is using the same e-maill address as signature.asc Description: Digital signature
[PATCH] drm/exynos: resolve infinite loop issue on multi-platform
This patch resolves temporarily infinite loop issue incurred
when Exynos drm driver is enabled and multi-platform kernel
is used by registering Exynos drm device object only in case
of Exynos SoC. So this patch will be replaced with more generic
way later.
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 443a206..ecc86aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -734,6 +734,18 @@ static int exynos_drm_init(void)
{
int ret;
+ /*
+* Register device object only in case of Exynos SoC.
+*
+* Below codes resolves temporarily infinite loop issue incurred
+* by Exynos drm driver when using multi-platform kernel.
+* So these codes will be replaced with more generic way later.
+*/
+ if (!of_machine_is_compatible(samsung,exynos3)
+ !of_machine_is_compatible(samsung,exynos4)
+ !of_machine_is_compatible(samsung,exynos5))
+ return -ENODEV;
+
exynos_drm_pdev = platform_device_register_simple(exynos-drm, -1,
NULL, 0);
if (IS_ERR(exynos_drm_pdev))
--
1.7.9.5
--
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] thermal: cpu_cooling: Update always cpufreq policy with thermal constraints
Hello Eduardo Valentin,
On Thursday, November 06, 2014 2:17 AM, Eduardo Valentin wrote:
Hello Yadwinder,
On Wed, Nov 05, 2014 at 05:46:25PM +0530, Yadwinder Singh Brar wrote:
Existing code updates cupfreq policy only while executing
cpufreq_apply_cooling() function (i.e. when notify_device !=
NOTIFY_INVALID).
Correct. The case you mention is when we receive a notification from
cpufreq. But also, updates the cpufreq policy when the cooling device
changes state, a call from thermal framework.
I mentioned thermal framework case only, existing code updates
cupfreq policy only when (notify_device != NOTIFY_INVALID),
which happens only when notification comes from cpufreq_update_policy
while changing cooling device's state(i.e. cpufreq_apply_cooling()).
In case of other notifications notify_device is always NOTIFY_INVALID.
It doesn't apply constraints when cpufreq policy update happens from
any other place but it should update the cpufreq policy with thermal
constraints every time when there is a cpufreq policy update, to keep
state of cpufreq_cooling_device and max_feq of cpufreq policy in
sync.
I am not sure I follow you here. Can you please elaborate on 'any other
places'? Could you please mention (also in the commit log) what are the
case the current code does not cover? For instance, the
cpufreq_apply_cooling gets called on notification coming from thermal
subsystem, and for changes in cpufreq subsystem,
cpufreq_thermal_notifier is called.
Other places mean possible places from where cpufreq_update_policy()
can be called at runtime, an instance in present kernel is cpufreq_resume().
But since cpufreq_update_policy() is an exposed API, I think
for robustness, generic cpu cooling should be able to take care of any
possible case(in future as well).
This patch modifies code to maintain a global cpufreq_dev_list and
get
corresponding cpufreq_cooling_device for policy's cpu from
cpufreq_dev_list when there is any policy update.
OK. Please give real examples of when the current code fails to catch
the event.
While resuming cpufreq updates cpufreq_policy for boot cpu and it
restores default policy-usr_policy irrespective of cooling device's
cpufreq_state since notification gets missed because (notify_device ==
NOTIFY_INVALID).
Another thing, Rather I would say an issue, I observed is that
Userspace is able to change max_freq irrespective of cooling
device's state, as notification gets missed.
BR,
Eduardo Valentin
Signed-off-by: Yadwinder Singh Brar yadi.b...@samsung.com
---
drivers/thermal/cpu_cooling.c | 37 ---
--
1 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/thermal/cpu_cooling.c
b/drivers/thermal/cpu_cooling.c index 1ab0018..5546278 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -50,15 +50,14 @@ struct cpufreq_cooling_device {
unsigned int cpufreq_state;
unsigned int cpufreq_val;
struct cpumask allowed_cpus;
+ struct list_head node;
};
static DEFINE_IDR(cpufreq_idr);
static DEFINE_MUTEX(cooling_cpufreq_lock);
static unsigned int cpufreq_dev_count;
-/* notify_table passes value to the CPUFREQ_ADJUST callback
function.
*/ -#define NOTIFY_INVALID NULL -static struct cpufreq_cooling_device
*notify_device;
+static LIST_HEAD(cpufreq_dev_list);
/**
* get_idr - function to get a unique id.
@@ -287,15 +286,12 @@ static int cpufreq_apply_cooling(struct
cpufreq_cooling_device *cpufreq_device,
cpufreq_device-cpufreq_state = cooling_state;
cpufreq_device-cpufreq_val = clip_freq;
- notify_device = cpufreq_device;
for_each_cpu(cpuid, mask) {
if (is_cpufreq_valid(cpuid))
cpufreq_update_policy(cpuid);
}
- notify_device = NOTIFY_INVALID;
-
return 0;
}
@@ -316,21 +312,27 @@ static int cpufreq_thermal_notifier(struct
notifier_block *nb, {
struct cpufreq_policy *policy = data;
unsigned long max_freq = 0;
+ struct cpufreq_cooling_device *cpufreq_dev;
- if (event != CPUFREQ_ADJUST || notify_device == NOTIFY_INVALID)
+ if (event != CPUFREQ_ADJUST)
return 0;
- if (cpumask_test_cpu(policy-cpu, notify_device-allowed_cpus))
- max_freq = notify_device-cpufreq_val;
- else
- return 0;
+ mutex_lock(cooling_cpufreq_lock);
+ list_for_each_entry(cpufreq_dev, cpufreq_dev_list, node) {
+ if (!cpumask_test_cpu(policy-cpu,
+ cpufreq_dev-allowed_cpus))
+ continue;
- /* Never exceed user_policy.max */
- if (max_freq policy-user_policy.max)
- max_freq = policy-user_policy.max;
+ max_freq = cpufreq_dev-cpufreq_val;
I think I missed to post updated patch,
Actually it should be :
+ if (!cpufreq_dev-cpufreq_val)
+
Re: asix: Don't reset PHY on if_up for ASIX 88772 breaks net on arndale platform
On Thu, Nov 06, 2014 at 10:01:04AM +, Charles Keepax wrote: On Thu, Nov 06, 2014 at 11:06:51AM +0200, Riku Voipio wrote: The asix on arndale comes semi-configured from u-boot, which I guess is not the state kernel expects it to come in. At least in my case where I use tftp from u-boot to load my kernel. So probably the full reset is needed here to make the asix chip come to a truly pristine state. The commit that Michel partially reverted (by returning to use ax88772_link_reset instead of ax88772_reset), indicates that a strong reset is needed for suspend/resume as well: Ok I think I have cracked this one. I am pretty sure you are right that the USB comes to us in a strange state and needs a full reset, but that only needs to happen once when the driver is bound in. So there is some code in ax88772_bind that appears to try to reset the device but does a lot less than ax88772_reset and I think that must be the problem. Applying the following on top of the patch we have been debating I think will make everything work for all of us: The patch below on top of 3.18-rc3 fixes arndale network for me. Tested-by: Riku Voipio riku.voi...@linaro.org --- a/drivers/net/usb/asix_devices.c +++ b/drivers/net/usb/asix_devices.c @@ -465,19 +465,7 @@ static int ax88772_bind(struct usbnet *dev, struct usb_interface *in return ret; } - ret = asix_sw_reset(dev, AX_SWRESET_IPPD | AX_SWRESET_PRL); - if (ret 0) - return ret; - - msleep(150); - - ret = asix_sw_reset(dev, AX_SWRESET_CLEAR); - if (ret 0) - return ret; - - msleep(150); - - ret = asix_sw_reset(dev, embd_phy ? AX_SWRESET_IPRL : AX_SWRESET_PRTE); + ax88772_reset(dev); If you guys could test that and let me know how you get on I will send in a proper patch if it looks good. Thanks, Charles -- 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: resolve infinite loop issue on multi-platform
On 06.11.2014 11:32, Inki Dae wrote:
This patch resolves temporarily infinite loop issue incurred
when Exynos drm driver is enabled and multi-platform kernel
is used by registering Exynos drm device object only in case
of Exynos SoC. So this patch will be replaced with more generic
way later.
Does not help for Rinato board.
On Rinato:
---
Failed to find PMU node
Registering SWP/SWPB emulation handler
mmc0: BKOPS_EN bit is not set
mmc_host mmc0: Bus speed (slot 0) = 1Hz (slot req 1Hz,
actual 1HZ div = 0)
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
mmc0: new HS200 MMC card at address 0001
platform exynos-drm: Driver exynos-drm requests probe deferral
mmcblk0: mmc0:0001 F5X5MA 3.64 GiB
mmcblk0boot0: mmc0:0001 F5X5MA partition 1 4.00 MiB
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
mmcblk0boot1: mmc0:0001 F5X5MA partition 2 4.00 MiB
platform exynos-drm: Driver exynos-drm requests probe deferral
mmcblk0rpmb: mmc0:0001 F5X5MA partition 3 512 KiB
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
platform exynos-drm: Driver exynos-drm requests probe deferral
mmcblk0: p1 p2 p3 p4 p5 p6 p7
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
platform exynos-drm: Driver exynos-drm requests probe deferral
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
platform exynos-drm: Driver exynos-drm requests probe deferral
and so on...
---
I do not know whether it is related but Trats2 board cannot boot due to
lockup after:
[drm] Initialized drm 1.1.0 20060810
(with or without the patch)
https://lkml.org/lkml/2014/11/6/125
Best regards,
Krzysztof
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 443a206..ecc86aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -734,6 +734,18 @@ static int exynos_drm_init(void)
{
int ret;
+ /*
+ * Register device object only in case of Exynos SoC.
+ *
+ * Below codes resolves temporarily infinite loop issue incurred
+ * by Exynos drm driver when using multi-platform kernel.
+ * So these codes will be replaced with more generic way later.
+ */
+ if (!of_machine_is_compatible(samsung,exynos3)
+ !of_machine_is_compatible(samsung,exynos4)
+ !of_machine_is_compatible(samsung,exynos5))
+ return -ENODEV;
+
exynos_drm_pdev = platform_device_register_simple(exynos-drm, -1,
NULL, 0);
if (IS_ERR(exynos_drm_pdev))
--
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: resolve infinite loop issue on multi-platform
On 2014년 11월 06일 21:11, Krzysztof Kozłowski wrote:
On 06.11.2014 11:32, Inki Dae wrote:
This patch resolves temporarily infinite loop issue incurred
when Exynos drm driver is enabled and multi-platform kernel
is used by registering Exynos drm device object only in case
of Exynos SoC. So this patch will be replaced with more generic
way later.
Does not help for Rinato board.
On Rinato:
---
Failed to find PMU node
Registering SWP/SWPB emulation handler
mmc0: BKOPS_EN bit is not set
mmc_host mmc0: Bus speed (slot 0) = 1Hz (slot req 1Hz,
actual 1HZ div = 0)
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
mmc0: new HS200 MMC card at address 0001
platform exynos-drm: Driver exynos-drm requests probe deferral
mmcblk0: mmc0:0001 F5X5MA 3.64 GiB
mmcblk0boot0: mmc0:0001 F5X5MA partition 1 4.00 MiB
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
mmcblk0boot1: mmc0:0001 F5X5MA partition 2 4.00 MiB
platform exynos-drm: Driver exynos-drm requests probe deferral
mmcblk0rpmb: mmc0:0001 F5X5MA partition 3 512 KiB
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
platform exynos-drm: Driver exynos-drm requests probe deferral
mmcblk0: p1 p2 p3 p4 p5 p6 p7
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
platform exynos-drm: Driver exynos-drm requests probe deferral
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
platform exynos-drm: Driver exynos-drm requests probe deferral
and so on...
---
Can you show me compatible string placed on top of exynos3250-rinato.dts
file? If the compatible has samsung,exynos3 it should be no problem
with this patch. And the rinato dts file we posted to mainline has the
compatible string.
I do not know whether it is related but Trats2 board cannot boot due to
lockup after:
[drm] Initialized drm 1.1.0 20060810
(with or without the patch)
https://lkml.org/lkml/2014/11/6/125
hmm... it's strange because my trats2 board works well with this patch.
Which kernel did you test? And how can I reproduce above lockup?
Thanks,
Inki Dae
Best regards,
Krzysztof
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 443a206..ecc86aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -734,6 +734,18 @@ static int exynos_drm_init(void)
{
int ret;
+/*
+ * Register device object only in case of Exynos SoC.
+ *
+ * Below codes resolves temporarily infinite loop issue incurred
+ * by Exynos drm driver when using multi-platform kernel.
+ * So these codes will be replaced with more generic way later.
+ */
+if (!of_machine_is_compatible(samsung,exynos3)
+!of_machine_is_compatible(samsung,exynos4)
+!of_machine_is_compatible(samsung,exynos5))
+return -ENODEV;
+
exynos_drm_pdev = platform_device_register_simple(exynos-drm, -1,
NULL, 0);
if (IS_ERR(exynos_drm_pdev))
--
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
Re: [PATCH 1/9] drm/exynos: remove uneeded declaration of struct dma_iommu_mapping
Hi Inki,
Could you please give a review to this series?
Thanks.
Gustavo
2014-10-31 Gustavo Padovan gust...@padovan.org:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
It is not even used in this header anymore.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_iommu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.h
b/drivers/gpu/drm/exynos/exynos_drm_iommu.h
index 72376d4..35d2588 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.h
@@ -40,7 +40,6 @@ static inline bool is_drm_iommu_supported(struct drm_device
*drm_dev)
#else
-struct dma_iommu_mapping;
static inline int drm_create_iommu_mapping(struct drm_device *drm_dev)
{
return 0;
--
1.9.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: asix: Don't reset PHY on if_up for ASIX 88772 breaks net on arndale platform
Hello Riku and Charles, I tried this with my original patch and the suggested patch applied, this seems to work for me too. One thing that bothers me, is the suspend / resume situation; usbnet.c seems to call the bind( ) on probe( ). Suspend / resume do not seem to call bind( ) directly. As Riku pointed out, the original patch I reverted was because of suspend/resume issues. I wonder if this will still work? Kind regards, Michel Stam -Original Message- From: Riku Voipio [mailto:riku.voi...@iki.fi] Sent: Thursday, November 06, 2014 13:04 PM To: Charles Keepax Cc: Riku Voipio; Stam, Michel [FINT]; fre...@asix.com.tw; da...@davemloft.net; linux-...@vger.kernel.org; net...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-samsung-soc@vger.kernel.org Subject: Re: asix: Don't reset PHY on if_up for ASIX 88772 breaks net on arndale platform On Thu, Nov 06, 2014 at 10:01:04AM +, Charles Keepax wrote: On Thu, Nov 06, 2014 at 11:06:51AM +0200, Riku Voipio wrote: The asix on arndale comes semi-configured from u-boot, which I guess is not the state kernel expects it to come in. At least in my case where I use tftp from u-boot to load my kernel. So probably the full reset is needed here to make the asix chip come to a truly pristine state. The commit that Michel partially reverted (by returning to use ax88772_link_reset instead of ax88772_reset), indicates that a strong reset is needed for suspend/resume as well: Ok I think I have cracked this one. I am pretty sure you are right that the USB comes to us in a strange state and needs a full reset, but that only needs to happen once when the driver is bound in. So there is some code in ax88772_bind that appears to try to reset the device but does a lot less than ax88772_reset and I think that must be the problem. Applying the following on top of the patch we have been debating I think will make everything work for all of us: The patch below on top of 3.18-rc3 fixes arndale network for me. Tested-by: Riku Voipio riku.voi...@linaro.org --- a/drivers/net/usb/asix_devices.c +++ b/drivers/net/usb/asix_devices.c @@ -465,19 +465,7 @@ static int ax88772_bind(struct usbnet *dev, struct usb_interface *in return ret; } - ret = asix_sw_reset(dev, AX_SWRESET_IPPD | AX_SWRESET_PRL); - if (ret 0) - return ret; - - msleep(150); - - ret = asix_sw_reset(dev, AX_SWRESET_CLEAR); - if (ret 0) - return ret; - - msleep(150); - - ret = asix_sw_reset(dev, embd_phy ? AX_SWRESET_IPRL : AX_SWRESET_PRTE); + ax88772_reset(dev); If you guys could test that and let me know how you get on I will send in a proper patch if it looks good. Thanks, Charles -- 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: asix: Don't reset PHY on if_up for ASIX 88772 breaks net on arndale platform
On Thu, Nov 06, 2014 at 01:39:07PM +0100, Stam, Michel [FINT] wrote: Hello Riku and Charles, I tried this with my original patch and the suggested patch applied, this seems to work for me too. One thing that bothers me, is the suspend / resume situation; usbnet.c seems to call the bind( ) on probe( ). Suspend / resume do not seem to call bind( ) directly. As Riku pointed out, the original patch I reverted was because of suspend/resume issues. I wonder if this will still work? I seem to remember I had a few issues with Arndale suspend and resume last time I tried it anyways, so not sure I will be able to test for that. But I will have a go. But in either case I guess a fix for that is probably orthogonal to my suggested fix here, as it looks pretty clear we intended to fully reset the device in bind and were appartently not doing that. So this patch is probably a needed fix anyway. Even if there are seperate issues relating to suspend and resume. Thanks, Charles -- 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: resolve infinite loop issue on multi-platform
On 2014년 11월 06일 22:00, Krzysztof Kozlowski wrote:
On czw, 2014-11-06 at 21:32 +0900, Inki Dae wrote:
On 2014년 11월 06일 21:11, Krzysztof Kozłowski wrote:
On 06.11.2014 11:32, Inki Dae wrote:
This patch resolves temporarily infinite loop issue incurred
when Exynos drm driver is enabled and multi-platform kernel
is used by registering Exynos drm device object only in case
of Exynos SoC. So this patch will be replaced with more generic
way later.
Does not help for Rinato board.
On Rinato:
---
Failed to find PMU node
Registering SWP/SWPB emulation handler
mmc0: BKOPS_EN bit is not set
mmc_host mmc0: Bus speed (slot 0) = 1Hz (slot req 1Hz,
actual 1HZ div = 0)
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
mmc0: new HS200 MMC card at address 0001
platform exynos-drm: Driver exynos-drm requests probe deferral
mmcblk0: mmc0:0001 F5X5MA 3.64 GiB
mmcblk0boot0: mmc0:0001 F5X5MA partition 1 4.00 MiB
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
mmcblk0boot1: mmc0:0001 F5X5MA partition 2 4.00 MiB
platform exynos-drm: Driver exynos-drm requests probe deferral
mmcblk0rpmb: mmc0:0001 F5X5MA partition 3 512 KiB
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
platform exynos-drm: Driver exynos-drm requests probe deferral
mmcblk0: p1 p2 p3 p4 p5 p6 p7
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
platform exynos-drm: Driver exynos-drm requests probe deferral
exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
platform exynos-drm: Driver exynos-drm requests probe deferral
and so on...
---
Can you show me compatible string placed on top of exynos3250-rinato.dts
file? If the compatible has samsung,exynos3 it should be no problem
with this patch. And the rinato dts file we posted to mainline has the
compatible string.
model = Samsung Rinato board;
compatible = samsung,rinato-rev05, samsung,exynos3250,
samsung,exynos3;
The problem is samsung,exynos3 because the patch solves only issue on
multiplatform kernel run on non-exynos board. It does not solve the
problem on exynos board with DRM enabled but without all drivers.
Right, if you disabled all kms drivers and enabled only non-kms drivers
then the infinite loop will occur. However, this should be handled in
separated issue because without this patch, same issue will occur.
I do not know whether it is related but Trats2 board cannot boot due to
lockup after:
[drm] Initialized drm 1.1.0 20060810
(with or without the patch)
https://lkml.org/lkml/2014/11/6/125
hmm... it's strange because my trats2 board works well with this patch.
Which kernel did you test? And how can I reproduce above lockup?
Just boot up next-2014110{456} with kernel config attached in mentioned
email.
It looks like other issue regardless of this patch. If the board dts
file includes compatible string that Exynos drm driver is checking then
Exynos drm driver has no any change - having same logic.
Thanks,
Inki Dae
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: asix: Don't reset PHY on if_up for ASIX 88772 breaks net onarndale platform
Hello Charles and Riku, I've quickly tested this on a 3.10 kernel i had around; I enabled CONFIG_PM, CONFIG_PM_RUNTIME, CONFIG_PM_AUTOSLEEP, CONFIG_SUSPEND, CONFIG_SUSPEND_FREEZER, CONFIG_FREEZER in the kernel (by default they are disabled for our setup, I enabled anything regarded to runtime powermanagement to be sure I would trigger suspend/resume). Then: cd /sys/bus/usb/devices/1-2/power echo auto control echo 1 autosuspend echo 0 autosuspend_delay_ms echo enabled wakeup # make sure there's no processes routing traffic over the eth1 interface ifconfig eth1 down sleep 4 # sleep some arbitrary long time ifconfig eth1 up check dmesg; it will reset back to 100 Mbps/full duplex. This confirms that the suspend / resume does not work well. So long as the suspend is not triggered, it does seem to work, though. I cannot say whether the original issue that triggered this is still around; the ASIX chip setup we use is soldered to the PCB and hooked up to a fixed device on-board. I also tried to ping the device on the other side of the ASIX chip after the suspend/resume cycle, I could not ping it. I cannot conclusively say that this is due to the ASIX driver, as the device on the other side does not like switching PHY speeds (it may go into a non-responsive state). It is for this reason that we run it at half duplex/ 10Mbps at all times. As said; we are not using this kind of power management, so it does not raise any issues for us. I am merely pointing out that this may need work (in the future?). Kind regards, Michel Stam -Original Message- From: Charles Keepax [mailto:ckee...@opensource.wolfsonmicro.com] Sent: Thursday, November 06, 2014 13:47 PM To: Stam, Michel [FINT] Cc: Riku Voipio; fre...@asix.com.tw; da...@davemloft.net; linux-...@vger.kernel.org; net...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-samsung-soc@vger.kernel.org Subject: Re: asix: Don't reset PHY on if_up for ASIX 88772 breaks net onarndale platform On Thu, Nov 06, 2014 at 01:39:07PM +0100, Stam, Michel [FINT] wrote: Hello Riku and Charles, I tried this with my original patch and the suggested patch applied, this seems to work for me too. One thing that bothers me, is the suspend / resume situation; usbnet.c seems to call the bind( ) on probe( ). Suspend / resume do not seem to call bind( ) directly. As Riku pointed out, the original patch I reverted was because of suspend/resume issues. I wonder if this will still work? I seem to remember I had a few issues with Arndale suspend and resume last time I tried it anyways, so not sure I will be able to test for that. But I will have a go. But in either case I guess a fix for that is probably orthogonal to my suggested fix here, as it looks pretty clear we intended to fully reset the device in bind and were appartently not doing that. So this patch is probably a needed fix anyway. Even if there are seperate issues relating to suspend and resume. Thanks, Charles -- 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: asix: Don't reset PHY on if_up for ASIX 88772 breaks net onarndale platform
On Thu, Nov 06, 2014 at 03:01:56PM +0100, Stam, Michel [FINT] wrote: Hello Charles and Riku, I've quickly tested this on a 3.10 kernel i had around; I enabled CONFIG_PM, CONFIG_PM_RUNTIME, CONFIG_PM_AUTOSLEEP, CONFIG_SUSPEND, CONFIG_SUSPEND_FREEZER, CONFIG_FREEZER in the kernel (by default they are disabled for our setup, I enabled anything regarded to runtime powermanagement to be sure I would trigger suspend/resume). Then: cd /sys/bus/usb/devices/1-2/power echo auto control echo 1 autosuspend echo 0 autosuspend_delay_ms echo enabled wakeup # make sure there's no processes routing traffic over the eth1 interface ifconfig eth1 down sleep 4 # sleep some arbitrary long time ifconfig eth1 up check dmesg; it will reset back to 100 Mbps/full duplex. This confirms that the suspend / resume does not work well. So long as the suspend is not triggered, it does seem to work, though. I cannot say whether the original issue that triggered this is still around; the ASIX chip setup we use is soldered to the PCB and hooked up to a fixed device on-board. I also tried to ping the device on the other side of the ASIX chip after the suspend/resume cycle, I could not ping it. I cannot conclusively say that this is due to the ASIX driver, as the device on the other side does not like switching PHY speeds (it may go into a non-responsive state). It is for this reason that we run it at half duplex/ 10Mbps at all times. As said; we are not using this kind of power management, so it does not raise any issues for us. I am merely pointing out that this may need work (in the future?). Cool thanks for checking this I will make a note in the commit message that suspend/resume might need some more work. Thanks, Charles -- 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] drm/exynos: resolve infinite loop issue on non multi-platform
This patch resovles the infinite loop issue incurred
when Exyno drm driver is enabled but all kms drivers
are disabled on Exynos board by returning -EPROBE_DEFER
only in case that there is kms device registered.
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ecc86aa..14c6af7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -488,6 +488,12 @@ static struct component_match *exynos_drm_match_add(struct
device *dev)
mutex_lock(drm_component_lock);
+ /* Do not retry to probe if there is no any kms driver regitered. */
+ if (list_empty(drm_component_list)) {
+ mutex_unlock(drm_component_lock);
+ return ERR_PTR(-ENODEV);
+ }
+
list_for_each_entry(cdev, drm_component_list, list) {
/*
* Add components to master only in case that crtc and
--
1.7.9.5
--
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 RESEND v3 1/4] devicetree: power/mfd: max77693: Document new bindings for charger
Document new device tree bindings for Maxim 77693 charger driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Documentation/devicetree/bindings/mfd/max77693.txt | 45 ++
1 file changed, 45 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt
b/Documentation/devicetree/bindings/mfd/max77693.txt
index 01e9f30fe678..38e64405e98d 100644
--- a/Documentation/devicetree/bindings/mfd/max77693.txt
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -41,6 +41,41 @@ Optional properties:
To get more informations, please refer to documentaion.
[*] refer Documentation/devicetree/bindings/pwm/pwm.txt
+- charger : Node configuring the charger driver.
+ If present, required properties:
+ - compatible : Must be maxim,max77693-charger.
+
+ Optional properties (if not set, defaults will be used):
+ - maxim,constant-microvolt : Battery constant voltage in uV. The charger
+will operate in fast charge constant current mode till battery voltage
+reaches this level. Then the charger will switch to fast charge constant
+voltage mode. Also vsys (system voltage) will be set to this value when
+DC power is supplied but charger is not enabled.
+Valid values: 365 - 440, step by 25000 (rounded down)
+Default: 420
+
+ - maxim,min-system-microvolt : Minimal system voltage in uV.
+Valid values: 300 - 370, step by 10 (rounded down)
+Default: 360
+
+ - maxim,thermal-regulation-celsius : Temperature in Celsius for entering
+high temperature charging mode. If die temperature exceeds this value
+the charging current will be reduced by 105 mA/Celsius.
+Valid values: 70, 85, 100, 115
+Default: 100
+
+ - maxim,battery-overcurrent-microamp : Overcurrent protection threshold
+in uA (current from battery to system).
+Valid values: 200 - 350, step by 25 (rounded down)
+Default: 350
+
+ - maxim,charge-input-threshold-microvolt : Threshold voltage in uV for
+triggering input voltage regulation loop. If input voltage decreases
+below this value, the input current will be reduced to reach the
+threshold voltage.
+Valid values: 430, 470, 480, 490
+Default: 430
+
Example:
max77693@66 {
compatible = maxim,max77693;
@@ -73,4 +108,14 @@ Example:
pwms = pwm 0 4 0;
pwm-names = haptic;
};
+
+ charger {
+ compatible = maxim,max77693-charger;
+
+ maxim,constant-microvolt = 420;
+ maxim,min-system-microvolt = 360;
+ maxim,thermal-regulation-celsius = 75;
+ maxim,battery-overcurrent-microamp = 300;
+ maxim,charge-input-threshold-microvolt = 430;
+ };
};
--
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 RESEND v3 3/4] power: max77693: Add charger driver for Maxim 77693
Add new driver for Maxim 77693 switch-mode charger (part of max77693
MFD driver) providing power supply class information to userspace.
The charger has +20V tolerant input. Current input can be set from 0 to
2.58 A. The charger can deliver up to 2.1 A to the battery or 3.5 A to
the system (when supplying additional current from battery to system).
The driver is configured through DTS (battery and system related
settings) and sysfs entries (timers and top-off charging threshold).
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Acked-By: Sebastian Reichel s...@kernel.org
---
drivers/power/Kconfig| 6 +
drivers/power/Makefile | 1 +
drivers/power/max77693_charger.c | 763 +++
3 files changed, 770 insertions(+)
create mode 100644 drivers/power/max77693_charger.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 0108c2af005b..77e6cd7bb801 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -332,6 +332,12 @@ config CHARGER_MAX14577
Say Y to enable support for the battery charger control sysfs and
platform data of MAX14577/77836 MUICs.
+config CHARGER_MAX77693
+ tristate Maxim MAX77693 battery charger driver
+ depends on MFD_MAX77693
+ help
+ Say Y to enable support for the Maxim MAX77693 battery charger.
+
config CHARGER_MAX8997
tristate Maxim MAX8997/MAX8966 PMIC battery charger driver
depends on MFD_MAX8997 REGULATOR_MAX8997
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index dfa894273926..2d7ad66cc7d6 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_CHARGER_LP8788) += lp8788-charger.o
obj-$(CONFIG_CHARGER_GPIO) += gpio-charger.o
obj-$(CONFIG_CHARGER_MANAGER) += charger-manager.o
obj-$(CONFIG_CHARGER_MAX14577) += max14577_charger.o
+obj-$(CONFIG_CHARGER_MAX77693) += max77693_charger.o
obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o
obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o
obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o
diff --git a/drivers/power/max77693_charger.c b/drivers/power/max77693_charger.c
new file mode 100644
index ..dfdbcc2f0795
--- /dev/null
+++ b/drivers/power/max77693_charger.c
@@ -0,0 +1,763 @@
+/*
+ * max77693_charger.c - Battery charger driver for the Maxim 77693
+ *
+ * Copyright (C) 2014 Samsung Electronics
+ * Krzysztof Kozlowski k.kozlow...@samsung.com
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+#include linux/regmap.h
+#include linux/mfd/max77693.h
+#include linux/mfd/max77693-private.h
+
+static const char *max77693_charger_name = max77693-charger;
+static const char *max77693_charger_model = MAX77693;
+static const char *max77693_charger_manufacturer = Maxim Integrated;
+
+struct max77693_charger {
+ struct device *dev;
+ struct max77693_dev *max77693;
+ struct power_supply charger;
+
+ struct max77693_charger_platform_data *pdata;
+};
+
+static int max77693_get_charger_state(struct regmap *regmap)
+{
+ int state;
+ unsigned int data;
+
+ if (regmap_read(regmap, MAX77693_CHG_REG_CHG_DETAILS_01, data) 0)
+ return POWER_SUPPLY_STATUS_UNKNOWN;
+
+ data = CHG_DETAILS_01_CHG_MASK;
+ data = CHG_DETAILS_01_CHG_SHIFT;
+
+ switch (data) {
+ case MAX77693_CHARGING_PREQUALIFICATION:
+ case MAX77693_CHARGING_FAST_CONST_CURRENT:
+ case MAX77693_CHARGING_FAST_CONST_VOLTAGE:
+ case MAX77693_CHARGING_TOP_OFF:
+ /* In high temp the charging current is reduced, but still charging */
+ case MAX77693_CHARGING_HIGH_TEMP:
+ state = POWER_SUPPLY_STATUS_CHARGING;
+ break;
+ case MAX77693_CHARGING_DONE:
+ state = POWER_SUPPLY_STATUS_FULL;
+ break;
+ case MAX77693_CHARGING_TIMER_EXPIRED:
+ case MAX77693_CHARGING_THERMISTOR_SUSPEND:
+ state = POWER_SUPPLY_STATUS_NOT_CHARGING;
+ break;
+ case MAX77693_CHARGING_OFF:
+ case MAX77693_CHARGING_OVER_TEMP:
+ case MAX77693_CHARGING_WATCHDOG_EXPIRED:
+ state = POWER_SUPPLY_STATUS_DISCHARGING;
+ break;
+ case MAX77693_CHARGING_RESERVED:
+ default:
+ state = POWER_SUPPLY_STATUS_UNKNOWN;
+ }
+
+
[PATCH RESEND v3 4/4] Documentation: power: max77693-charger: Document exported sysfs entry
Document the settings exported by max77693 charger driver through sysfs entries: - fast_charge_timer - top_off_threshold_current - top_off_timer Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- Documentation/ABI/testing/sysfs-class-power | 42 + 1 file changed, 42 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power index 909e7602c717..369d2a2d7d3e 100644 --- a/Documentation/ABI/testing/sysfs-class-power +++ b/Documentation/ABI/testing/sysfs-class-power @@ -32,3 +32,45 @@ Description: Valid values: - 5, 6 or 7 (hours), - 0: disabled. + +What: /sys/class/power_supply/max77693-charger/device/fast_charge_timer +Date: January 2015 +KernelVersion: 3.19.0 +Contact: Krzysztof Kozlowski k.kozlow...@samsung.com +Description: + This entry shows and sets the maximum time the max77693 + charger operates in fast-charge mode. When the timer expires + the device will terminate fast-charge mode (charging current + will drop to 0 A) and will trigger interrupt. + + Valid values: + - 4 - 16 (hours), step by 2 (rounded down) + - 0: disabled. + +What: /sys/class/power_supply/max77693-charger/device/top_off_threshold_current +Date: January 2015 +KernelVersion: 3.19.0 +Contact: Krzysztof Kozlowski k.kozlow...@samsung.com +Description: + This entry shows and sets the charging current threshold for + entering top-off charging mode. When charging current in fast + charge mode drops below this value, the charger will trigger + interrupt and start top-off charging mode. + + Valid values: + - 10 - 20 (microamps), step by 25000 (rounded down) + - 20 - 35 (microamps), step by 5 (rounded down) + - 0: disabled. + +What: /sys/class/power_supply/max77693-charger/device/top_off_timer +Date: January 2015 +KernelVersion: 3.19.0 +Contact: Krzysztof Kozlowski k.kozlow...@samsung.com +Description: + This entry shows and sets the maximum time the max77693 + charger operates in top-off charge mode. When the timer expires + the device will terminate top-off charge mode (charging current + will drop to 0 A) and will trigger interrupt. + + Valid values: + - 0 - 70 (minutes), step by 10 (rounded down) -- 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 RESEND v3 0/4] power/mfd: Add max77693 charger driver
Hi, I got ack from Sebastian [1] but only for charger driver patch. This means that I still need an ack for documentation (bindings, sysfs)... Changes since v2 1. Add ack from Sebastian Reichel (charger driver). 2. Drop patch mfd: max77693: Map charger device to its own of_node (applied by Lee Jones). Changes since v1 1. Add patch 2/5: mfd: max77693: Map charger device to its own of_node (forgot to send it in v1) 2. Remove patches for DTS and configs. I'll send them later. 3. Add ack from Lee Jones (patch 3/5). Description === The patchset adds max77693 charger driver present on Trats2 board (and Galaxy S III). The driver configures battery charger and exposes power supply interface. Driver is necessary to provide full charging stack on Trats2 device (extcon, charger-manager etc.). [1] https://lkml.org/lkml/2014/10/27/774 Best regards, Krzysztof Krzysztof Kozlowski (4): devicetree: power/mfd: max77693: Document new bindings for charger mfd: max77693: Add defines for MAX77693 charger driver power: max77693: Add charger driver for Maxim 77693 Documentation: power: max77693-charger: Document exported sysfs entry Documentation/ABI/testing/sysfs-class-power| 42 ++ Documentation/devicetree/bindings/mfd/max77693.txt | 45 ++ drivers/power/Kconfig | 6 + drivers/power/Makefile | 1 + drivers/power/max77693_charger.c | 763 + include/linux/mfd/max77693-private.h | 108 +++ include/linux/mfd/max77693.h | 8 + 7 files changed, 973 insertions(+) create mode 100644 drivers/power/max77693_charger.c -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: resolve infinite loop issue on non multi-platform
Hi Inki, With all respect, On 06/11/14 14:10, Inki Dae wrote: This patch resovles the infinite loop issue incurred when Exyno drm driver is enabled but all kms drivers are disabled on Exynos board by returning -EPROBE_DEFER only in case that there is kms device registered. I believe it's preferred to add changelog, the original reporter (so that they can test) and the bug report in the commit message. Something like the following: v2: - Use drm_component_list the rather than of_machine_is_compatible to check for presence of an Exynos SoC. Cc: Matwey V. Kornilov matwey.korni...@gmail.com References: https://bugzilla.kernel.org/show_bug.cgi?id=87691 -- 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: resolve infinite loop issue on non multi-platform
On 06/11/14 15:44, Emil Velikov wrote: Hi Inki, With all respect, On 06/11/14 14:10, Inki Dae wrote: This patch resovles the infinite loop issue incurred when Exyno drm driver is enabled but all kms drivers are disabled on Exynos board by returning -EPROBE_DEFER only in case that there is kms device registered. I believe it's preferred to add changelog, the original reporter (so that they can test) and the bug report in the commit message. Something like the following: v2: - Use drm_component_list the rather than of_machine_is_compatible to check for presence of an Exynos SoC. Cc: Matwey V. Kornilov matwey.korni...@gmail.com References: https://bugzilla.kernel.org/show_bug.cgi?id=87691 I'm a genius. Please disregard the above. -Emil -- 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/4] PM / Domains: Remove pm_genpd_dev_need_restore() API
[dropping some addresses from Cc]
On 03/10/14 12:36, Ulf Hansson wrote:
On 2 October 2014 17:54, Sylwester Nawrocki s.nawro...@samsung.com wrote:
On 02/10/14 15:30, Ulf Hansson wrote:
[...]
Correct me if I am wrong, but I think in principle these exynos
drivers don't use pm_runtime_set_active() during -probe() and are
instead relying on CONFIG_PM_RUNTIME to be enabled.
Yes, pm_runtime_set_active() is not used in probe(), I believe this
is not required. In case of those IP blocks there is no use of activating
them during probe(). Instead we check if PM_RUNTIME is enabled through
pm_runtime_enabled() helper and enable the device clock(s) if not.
I agree it all doesn't quite work in current mainline for !PM_RUNTIME,
since there is nothing ensuring that the power domains are enabled
in such kernel configuration.
That's not a good behaviour. If these drivers are build without
CONFIG_PM_RUNTIME - they won't work.
They wouldn't similarly work with pm_runtime_set_active() call in probe()
with CONFIG_PM_RUNTIME disabled, would they ?
Yes they would, although they require some minor additional adaptations.
Those resources that are enabled from the driver's runtime PM resume
callback, should also be enabled during -probe(). The
pm_runtime_set_active() will then update the state to reflect this.
Then, if CONFIG_PM_RUNTIME is enabled - the device will be scheduled
to go inactive from driver core (pm_request_idle()), after -probe()
has completed. Thus saving power if it's unused.
If CONFIG_PM_RUNTIME isn't enabled - the driver will still be
functional, since all resources are enabled during -probe().
OK, I suspected you also assumed enabling relevant resources, so the PM
state matches the hardware state.
Sorry for getting back late to this, now there is a regression on
Exynos seen in multiple drivers, i.e. affecting all the media and
video devices. Is this patch series going to be merged for v3.18 as
a regression fix ? If so I would need to update remaining drivers to
enable clocks and use pm_runtime_set_active() in probe().
I can see two options to fix bugs which appeared in Exynos after
merging the patch series switching to the OF generic power domain API:
1. merge this series and update the affected drivers for v3.18,
2. revert for now to the previous behaviour, doing something as
the patch below.
1. seems only a partial solution, since the regression remains for the
loadable modules which are loaded after late_initcall(). At that point
power domain may be disabled and the driver attempting to access
the hardware will hand the system.
It's also a bit not clear to me why there is an assumption that when
a power domain is initially enabled all its corresponding devices are
already also fully activated ?
int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
struct gpd_timing_data *td)
{
...
gpd_data-need_restore = genpd-status == GPD_STATE_POWER_OFF;
...
}
It seems correct to me to have initially the power domain enabled and some
devices inactive, e.g. if device's driver manages its clocks and didn't
turn them on yet.
-8
From c7dbc17e940db681d51941b3493e216cee6912f5 Mon Sep 17 00:00:00 2001
From: Sylwester Nawrocki s.nawro...@samsung.com
Date: Thu, 6 Nov 2014 16:44:05 +0100
Subject: [PATCH] PM / domains: Allow initial restoring of devices in active
domain
Currently a device in the power domain won't be initially runtime
resumed if it is added to an active power domain. In drivers which
don't enable all resources they manage and call pm_runtime_set_active()
in probe() there are now unbalanced runtime_resume() calls seen after
commit a4a8c2c4962bb655e7152c53a0eb6ca31c47f159
(ARM: exynos: Move to generic PM domain DT bindings).
To fix the regression revert to previous behaviour for Exynos platform.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
arch/arm/mach-exynos/pm_domains.c |2 +-
arch/arm/mach-s3c64xx/pm.c |4 ++--
arch/arm/mach-shmobile/pm-r8a7779.c |2 +-
arch/arm/mach-shmobile/pm-rmobile.c |2 +-
drivers/base/power/domain.c |8 ++--
include/linux/pm_domain.h |4 +++-
6 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index 20f2671..0b0bf68 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -157,7 +157,7 @@ static __init int exynos4_pm_init_power_domain(void)
no_clk:
on = __raw_readl(pd-base + 0x4) INT_LOCAL_PWR_EN;
- pm_genpd_init(pd-pd, NULL, !on);
+ pm_genpd_init(pd-pd, NULL, !on, true);
of_genpd_add_provider_simple(np, pd-pd);
}
diff --git a/arch/arm/mach-s3c64xx/pm.c b/arch/arm/mach-s3c64xx/pm.c
index aaf7bea..a347654 100644
--- a/arch/arm/mach-s3c64xx/pm.c
+++ b/arch/arm/mach-s3c64xx/pm.c
@@ -315,10 +315,10 @@
[PATCH v5 35/48] arm: Register with kernel power-off handler
Register with kernel power-off handler instead of setting pm_power_off
directly. Always use register_power_off_handler_simple as there is no
indication that more than one power-off handler is registered.
If the power-off handler only resets the system or puts the CPU in sleep mode,
select the fallback priority to indicate that the power-off handler is one
of last resort. If the power-off handler powers off the system, select the
default priority.
Cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
v5:
- Rebase to v3.18-rc3
v4:
- No change
v3:
- Replace poweroff in all newly introduced variables and in text
with power_off or power-off as appropriate
- Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
v2:
- Use defines to specify poweroff handler priorities
- Drop changes in arch/arm/mach-at91/setup.c (file removed upstream)
arch/arm/kernel/psci.c | 3 ++-
arch/arm/mach-at91/board-gsia18s.c | 3 ++-
arch/arm/mach-bcm/board_bcm2835.c | 3 ++-
arch/arm/mach-cns3xxx/cns3420vb.c | 3 ++-
arch/arm/mach-cns3xxx/core.c | 3 ++-
arch/arm/mach-highbank/highbank.c | 3 ++-
arch/arm/mach-imx/mach-mx31moboard.c | 3 ++-
arch/arm/mach-iop32x/em7210.c | 3 ++-
arch/arm/mach-iop32x/glantank.c| 3 ++-
arch/arm/mach-iop32x/iq31244.c | 3 ++-
arch/arm/mach-iop32x/n2100.c | 3 ++-
arch/arm/mach-ixp4xx/dsmg600-setup.c | 3 ++-
arch/arm/mach-ixp4xx/nas100d-setup.c | 3 ++-
arch/arm/mach-ixp4xx/nslu2-setup.c | 3 ++-
arch/arm/mach-omap2/board-omap3touchbook.c | 3 ++-
arch/arm/mach-orion5x/board-mss2.c | 3 ++-
arch/arm/mach-orion5x/dns323-setup.c | 9 ++---
arch/arm/mach-orion5x/kurobox_pro-setup.c | 3 ++-
arch/arm/mach-orion5x/ls-chl-setup.c | 3 ++-
arch/arm/mach-orion5x/ls_hgl-setup.c | 3 ++-
arch/arm/mach-orion5x/lsmini-setup.c | 3 ++-
arch/arm/mach-orion5x/mv2120-setup.c | 3 ++-
arch/arm/mach-orion5x/net2big-setup.c | 3 ++-
arch/arm/mach-orion5x/terastation_pro2-setup.c | 3 ++-
arch/arm/mach-orion5x/ts209-setup.c| 3 ++-
arch/arm/mach-orion5x/ts409-setup.c| 3 ++-
arch/arm/mach-pxa/corgi.c | 3 ++-
arch/arm/mach-pxa/mioa701.c| 3 ++-
arch/arm/mach-pxa/poodle.c | 3 ++-
arch/arm/mach-pxa/spitz.c | 3 ++-
arch/arm/mach-pxa/tosa.c | 3 ++-
arch/arm/mach-pxa/viper.c | 3 ++-
arch/arm/mach-pxa/z2.c | 7 ---
arch/arm/mach-pxa/zeus.c | 7 ---
arch/arm/mach-s3c24xx/mach-gta02.c | 3 ++-
arch/arm/mach-s3c24xx/mach-jive.c | 3 ++-
arch/arm/mach-s3c24xx/mach-vr1000.c| 3 ++-
arch/arm/mach-s3c64xx/mach-smartq.c| 3 ++-
arch/arm/mach-sa1100/generic.c | 3 ++-
arch/arm/mach-sa1100/simpad.c | 3 ++-
arch/arm/mach-u300/regulator.c | 3 ++-
arch/arm/mach-vt8500/vt8500.c | 3 ++-
arch/arm/xen/enlighten.c | 3 ++-
43 files changed, 94 insertions(+), 49 deletions(-)
diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index f73891b..a7a2b4a 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -264,7 +264,8 @@ static int psci_0_2_init(struct device_node *np)
arm_pm_restart = psci_sys_reset;
- pm_power_off = psci_sys_poweroff;
+ register_power_off_handler_simple(psci_sys_poweroff,
+ POWER_OFF_PRIORITY_DEFAULT);
out_put_node:
of_node_put(np);
diff --git a/arch/arm/mach-at91/board-gsia18s.c
b/arch/arm/mach-at91/board-gsia18s.c
index bf5cc55..e628c4a 100644
--- a/arch/arm/mach-at91/board-gsia18s.c
+++ b/arch/arm/mach-at91/board-gsia18s.c
@@ -521,7 +521,8 @@ static void gsia18s_power_off(void)
static int __init gsia18s_power_off_init(void)
{
- pm_power_off = gsia18s_power_off;
+ register_power_off_handler_simple(gsia18s_power_off,
+ POWER_OFF_PRIORITY_DEFAULT);
return 0;
}
diff --git a/arch/arm/mach-bcm/board_bcm2835.c
b/arch/arm/mach-bcm/board_bcm2835.c
index 70f2f39..1d75c76 100644
--- a/arch/arm/mach-bcm/board_bcm2835.c
+++ b/arch/arm/mach-bcm/board_bcm2835.c
@@ -111,7 +111,8 @@ static void __init bcm2835_init(void)
bcm2835_setup_restart();
if (wdt_regs)
- pm_power_off = bcm2835_power_off;
+ register_power_off_handler_simple(bcm2835_power_off,
+ POWER_OFF_PRIORITY_FALLBACK);
bcm2835_init_clocks();
diff --git a/arch/arm/mach-cns3xxx/cns3420vb.c
b/arch/arm/mach-cns3xxx/cns3420vb.c
index 6428bcc7..5c50461
Re: [PATCH] drm/exynos: resolve infinite loop issue on non multi-platform
On Thu, 2014-11-06 at 23:10 +0900, Inki Dae wrote:
This patch resovles the infinite loop issue incurred
when Exyno drm driver is enabled but all kms drivers
are disabled on Exynos board by returning -EPROBE_DEFER
only in case that there is kms device registered.
It would be nice if you could explain in the commit message/comment why
returning -EPROBE_DEFER causes an infinite loop and why it's the wrong
thing to do in this case?
Even if you know this probe will never succeed in the future (so
deferring is actually pointless), deferring really shouldn't trigger
infinte loops in calling code
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ecc86aa..14c6af7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -488,6 +488,12 @@ static struct component_match
*exynos_drm_match_add(struct device *dev)
mutex_lock(drm_component_lock);
+ /* Do not retry to probe if there is no any kms driver regitered. */
+ if (list_empty(drm_component_list)) {
+ mutex_unlock(drm_component_lock);
+ return ERR_PTR(-ENODEV);
+ }
+
list_for_each_entry(cdev, drm_component_list, list) {
/*
* Add components to master only in case that crtc and
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] thermal: cpu_cooling: Update always cpufreq policy with thermal constraints
Hello Yadwinder,
On Thu, Nov 06, 2014 at 04:26:27PM +0530, Yadwinder Singh Brar wrote:
Hello Eduardo Valentin,
On Thursday, November 06, 2014 2:17 AM, Eduardo Valentin wrote:
Hello Yadwinder,
On Wed, Nov 05, 2014 at 05:46:25PM +0530, Yadwinder Singh Brar wrote:
Existing code updates cupfreq policy only while executing
cpufreq_apply_cooling() function (i.e. when notify_device !=
NOTIFY_INVALID).
Correct. The case you mention is when we receive a notification from
cpufreq. But also, updates the cpufreq policy when the cooling device
changes state, a call from thermal framework.
I mentioned thermal framework case only, existing code updates
cupfreq policy only when (notify_device != NOTIFY_INVALID),
which happens only when notification comes from cpufreq_update_policy
while changing cooling device's state(i.e. cpufreq_apply_cooling()).
In case of other notifications notify_device is always NOTIFY_INVALID.
I see your point.
It doesn't apply constraints when cpufreq policy update happens from
any other place but it should update the cpufreq policy with thermal
constraints every time when there is a cpufreq policy update, to keep
state of cpufreq_cooling_device and max_feq of cpufreq policy in
sync.
I am not sure I follow you here. Can you please elaborate on 'any other
places'? Could you please mention (also in the commit log) what are the
case the current code does not cover? For instance, the
cpufreq_apply_cooling gets called on notification coming from thermal
subsystem, and for changes in cpufreq subsystem,
cpufreq_thermal_notifier is called.
Other places mean possible places from where cpufreq_update_policy()
can be called at runtime, an instance in present kernel is cpufreq_resume().
But since cpufreq_update_policy() is an exposed API, I think
for robustness, generic cpu cooling should be able to take care of any
possible case(in future as well).
OK. I understand now. Can you please improve your commit message by
adding the descriptions you mentioned here?
This patch modifies code to maintain a global cpufreq_dev_list and
get
corresponding cpufreq_cooling_device for policy's cpu from
cpufreq_dev_list when there is any policy update.
OK. Please give real examples of when the current code fails to catch
the event.
While resuming cpufreq updates cpufreq_policy for boot cpu and it
restores default policy-usr_policy irrespective of cooling device's
cpufreq_state since notification gets missed because (notify_device ==
NOTIFY_INVALID).
Another thing, Rather I would say an issue, I observed is that
Userspace is able to change max_freq irrespective of cooling
device's state, as notification gets missed.
Include also the examples above you gave.
Have you verified if with this patch the issue with userland goes away?
BR,
Eduardo Valentin
Signed-off-by: Yadwinder Singh Brar yadi.b...@samsung.com
---
drivers/thermal/cpu_cooling.c | 37 ---
--
1 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/thermal/cpu_cooling.c
b/drivers/thermal/cpu_cooling.c index 1ab0018..5546278 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -50,15 +50,14 @@ struct cpufreq_cooling_device {
unsigned int cpufreq_state;
unsigned int cpufreq_val;
struct cpumask allowed_cpus;
+ struct list_head node;
};
static DEFINE_IDR(cpufreq_idr);
static DEFINE_MUTEX(cooling_cpufreq_lock);
static unsigned int cpufreq_dev_count;
-/* notify_table passes value to the CPUFREQ_ADJUST callback
function.
*/ -#define NOTIFY_INVALID NULL -static struct cpufreq_cooling_device
*notify_device;
+static LIST_HEAD(cpufreq_dev_list);
/**
* get_idr - function to get a unique id.
@@ -287,15 +286,12 @@ static int cpufreq_apply_cooling(struct
cpufreq_cooling_device *cpufreq_device,
cpufreq_device-cpufreq_state = cooling_state;
cpufreq_device-cpufreq_val = clip_freq;
- notify_device = cpufreq_device;
for_each_cpu(cpuid, mask) {
if (is_cpufreq_valid(cpuid))
cpufreq_update_policy(cpuid);
}
- notify_device = NOTIFY_INVALID;
-
return 0;
}
@@ -316,21 +312,27 @@ static int cpufreq_thermal_notifier(struct
notifier_block *nb, {
struct cpufreq_policy *policy = data;
unsigned long max_freq = 0;
+ struct cpufreq_cooling_device *cpufreq_dev;
- if (event != CPUFREQ_ADJUST || notify_device == NOTIFY_INVALID)
+ if (event != CPUFREQ_ADJUST)
return 0;
- if (cpumask_test_cpu(policy-cpu, notify_device-allowed_cpus))
- max_freq = notify_device-cpufreq_val;
- else
- return 0;
+ mutex_lock(cooling_cpufreq_lock);
+ list_for_each_entry(cpufreq_dev, cpufreq_dev_list, node) {
+ if
Re: [PATCH v2 1/4] PM / Domains: Remove pm_genpd_dev_need_restore() API
[...]
Yes they would, although they require some minor additional adaptations.
Those resources that are enabled from the driver's runtime PM resume
callback, should also be enabled during -probe(). The
pm_runtime_set_active() will then update the state to reflect this.
Then, if CONFIG_PM_RUNTIME is enabled - the device will be scheduled
to go inactive from driver core (pm_request_idle()), after -probe()
has completed. Thus saving power if it's unused.
If CONFIG_PM_RUNTIME isn't enabled - the driver will still be
functional, since all resources are enabled during -probe().
OK, I suspected you also assumed enabling relevant resources, so the PM
state matches the hardware state.
Sorry for getting back late to this, now there is a regression on
Exynos seen in multiple drivers, i.e. affecting all the media and
video devices. Is this patch series going to be merged for v3.18 as
a regression fix ? If so I would need to update remaining drivers to
enable clocks and use pm_runtime_set_active() in probe().
Urgh!!! Let's see how we can work this out. I will be helping out and
give this the highest prio!
I did post a patchset for exynos 5 media gsc driver, I guess you have
seen it!? Now, that doesn't help us much but still.
https://www.mail-archive.com/linux-media@vger.kernel.org/msg80592.html
I can see two options to fix bugs which appeared in Exynos after
merging the patch series switching to the OF generic power domain API:
1. merge this series and update the affected drivers for v3.18,
This version is superseded by a v3. That takes a more solid approach
on how to power on the PM domain from the bus' -probe(). It's being
discussed currently.
[PATCH v3 0/9] PM / Domains: Fix race conditions during boot
You should be on cc-list of that.
2. revert for now to the previous behaviour, doing something as
the patch below.
1. seems only a partial solution, since the regression remains for the
loadable modules which are loaded after late_initcall(). At that point
power domain may be disabled and the driver attempting to access
the hardware will hand the system.
That was a limitation which is fixed in v3. I have tested loading
modules and it works nicely.
It's also a bit not clear to me why there is an assumption that when
a power domain is initially enabled all its corresponding devices are
already also fully activated ?
That's a very good question! I think the assumption is wrong!
Somehow we need to decouple that dependency. To me, typically the
need_restore flag should reflect the current runtime PM status of
the device, which isn't the case right now.
In the v3 version of this patchset, the PM domain will be powered on
from the bus's -probe(), which also means the need_restore flag
will initially always be set to false once the device are being
probed by the driver.
That means, those drivers not invoking pm_runtime_set_active() and
manually enable clk/resources during -probe(), but instead relies on
pm_runtime_get_sync() - will _not_ work. As you stated above for some
of the Exynos drivers.
Even if it's likely that most of these Exynos drivers should be using
pm_runtime_set_active() during -probe(), the key-problem lies in
genpd's wrong assumption about the device's runtime PM status, which
is stored in the need restore flag.
If we would fix the issue in genpd for the need_restore flag, that
should solve the regression for Exynos, don't you think?
I will immediately start working on a patch on genpd, which tries this
approach, I will keep you posted.
int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
struct gpd_timing_data *td)
{
...
gpd_data-need_restore = genpd-status == GPD_STATE_POWER_OFF;
...
}
It seems correct to me to have initially the power domain enabled and some
devices inactive, e.g. if device's driver manages its clocks and didn't
turn them on yet.
As stated, I fully agree!
[...]
Kind regards
Uffe
--
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 01/21] thermal: of: Extend of-thermal.c to provide number of trip points
Hello Lukasz,
On Thu, Oct 09, 2014 at 06:38:37PM +0200, Lukasz Majewski wrote:
This patch extends the of-thermal.c to provide information about number of
available trip points.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/thermal/of-thermal.c | 6 ++
drivers/thermal/thermal_core.h | 5 +
2 files changed, 11 insertions(+)
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index f8eb625..b2390d9 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -113,6 +113,12 @@ static int of_thermal_get_temp(struct
thermal_zone_device *tz,
return data-get_temp(data-sensor_data, temp);
}
+int of_thermal_get_ntrips(struct thermal_zone_device *tz)
+{
+ struct __thermal_zone *data = tz-devdata;
+ return data-ntrips;
+}
I am not against this addition. I just request you to document it
accordingly.
+
static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
enum thermal_trend *trend)
{
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index 3db339f..587ca5c 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -81,9 +81,14 @@ static inline void thermal_gov_user_space_unregister(void)
{}
#ifdef CONFIG_THERMAL_OF
int of_parse_thermal_zones(void);
void of_thermal_destroy_zones(void);
+int of_thermal_get_ntrips(struct thermal_zone_device *);
#else
static inline int of_parse_thermal_zones(void) { return 0; }
static inline void of_thermal_destroy_zones(void) { }
+static inline int of_thermal_get_ntrips(struct thermal_zone_device *)
+{
+ return 0;
+}
#endif
#endif /* __THERMAL_CORE_H__ */
--
2.0.0.rc2
signature.asc
Description: Digital signature
Re: [PATCH 02/21] thermal: of: Extend of-thermal.c to provide check if trip point is enabled
Hello Lukasz,
On Thu, Oct 09, 2014 at 06:38:38PM +0200, Lukasz Majewski wrote:
This patch extends the of-thermal.c to provide check if trip point is
enabled.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/thermal/of-thermal.c | 9 +
drivers/thermal/thermal_core.h | 5 +
2 files changed, 14 insertions(+)
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index b2390d9..23c8d6c 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -119,6 +119,15 @@ int of_thermal_get_ntrips(struct thermal_zone_device *tz)
return data-ntrips;
}
+int of_thermal_is_trip_en(struct thermal_zone_device *tz, int trip)
+{
+ struct __thermal_zone *data = tz-devdata;
+
+ if (trip = data-ntrips || trip 0)
+ return 0;
+ return 1;
might be worth using 'true' and 'false', just for the sake of code
readability.
+}
+
I am not against this addition. I just request you to document it
accordingly.
static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
enum thermal_trend *trend)
{
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index 587ca5c..ed8ff05 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -82,6 +82,7 @@ static inline void thermal_gov_user_space_unregister(void)
{}
int of_parse_thermal_zones(void);
void of_thermal_destroy_zones(void);
int of_thermal_get_ntrips(struct thermal_zone_device *);
+int of_thermal_is_trip_en(struct thermal_zone_device *, int);
#else
static inline int of_parse_thermal_zones(void) { return 0; }
static inline void of_thermal_destroy_zones(void) { }
@@ -89,6 +90,10 @@ static inline int of_thermal_get_ntrips(struct
thermal_zone_device *)
{
return 0;
}
+int of_thermal_is_trip_en(struct thermal_zone_device *, int)
this is supposed to be static inline.
+{
+ return 0;
+}
#endif
#endif /* __THERMAL_CORE_H__ */
--
2.0.0.rc2
signature.asc
Description: Digital signature
Re: [PATCH 03/21] thermal: of: Extend of-thermal.c to provide number of non critical trip points
On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote:
This patch extends the of-thermal.c to provide information about number of
available non critical (i.e. non HW) trip points in the system.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/thermal/of-thermal.c | 12
drivers/thermal/thermal_core.h | 5 +
2 files changed, 17 insertions(+)
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 23c8d6c..cd74e64 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -128,6 +128,18 @@ int of_thermal_is_trip_en(struct thermal_zone_device
*tz, int trip)
return 1;
}
+int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *tz)
+{
+ struct __thermal_zone *data = tz-devdata;
+ int i;
+
+ for (i = 0; i data-ntrips; i++)
+ if (data-trips[i].type != THERMAL_TRIP_CRITICAL)
+ continue;
+
+ return --i;
+}
+
I am not against this addition. But looks like we start to spread some
specific APIs that may not be used to other drivers. Maybe having a
single API to provide a read-only copy the list / array of trips might
be a better approach. I will think of a better way.
I also request you to document it accordingly.
static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
enum thermal_trend *trend)
{
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index ed8ff05..334a7be 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -83,6 +83,7 @@ int of_parse_thermal_zones(void);
void of_thermal_destroy_zones(void);
int of_thermal_get_ntrips(struct thermal_zone_device *);
int of_thermal_is_trip_en(struct thermal_zone_device *, int);
+int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *);
#else
static inline int of_parse_thermal_zones(void) { return 0; }
static inline void of_thermal_destroy_zones(void) { }
@@ -94,6 +95,10 @@ int of_thermal_is_trip_en(struct thermal_zone_device *,
int)
{
return 0;
}
+int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *)
here, it is supposed to be static inline.
+{
+ return 0;
+}
#endif
#endif /* __THERMAL_CORE_H__ */
--
2.0.0.rc2
signature.asc
Description: Digital signature
Re: [PATCH 04/21] thermal: of: Extend current of-thermal.c code to allow setting emulated temp
Hello,
On Thu, Oct 09, 2014 at 06:38:40PM +0200, Lukasz Majewski wrote:
Before this change it was only possible to set get_temp() and get_trend()
methods to be used in the common code handling passing parameters via
device tree to cpu-thermal CPU thermal zone device.
Now it is possible to also set emulated value of temperature for debug
purposes.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/thermal/of-thermal.c | 25 ++---
include/linux/thermal.h | 6 --
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index cd74e64..f206375 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -98,10 +98,22 @@ struct __thermal_zone {
void *sensor_data;
int (*get_temp)(void *, long *);
int (*get_trend)(void *, long *);
+ int (*set_emul_temp)(void *, unsigned long);
};
/*** DT thermal zone device callbacks ***/
+static int of_thermal_set_emul_temp(struct thermal_zone_device *tz,
+ unsigned long temp)
+{
+ struct __thermal_zone *data = tz-devdata;
+
+ if (!data-set_emul_temp)
+ return -EINVAL;
+
+ return data-set_emul_temp(data-sensor_data, temp);
+}
+
static int of_thermal_get_temp(struct thermal_zone_device *tz,
unsigned long *temp)
{
@@ -352,7 +364,8 @@ static struct thermal_zone_device *
thermal_zone_of_add_sensor(struct device_node *zone,
struct device_node *sensor, void *data,
int (*get_temp)(void *, long *),
-int (*get_trend)(void *, long *))
+int (*get_trend)(void *, long *),
+int (*set_emul_temp)(void *, unsigned long))
Thanks for improving the API. However, looking at what is above, it
starts to be pretty ugly. And for sure, this is not the last callback to
be added. I believe it is time to add a .ops in the of-thermal. While in
here, do you mind adding the .ops in a separated patch, then add the
.set_emul_temp in the .ops field?
{
struct thermal_zone_device *tzd;
struct __thermal_zone *tz;
@@ -366,10 +379,12 @@ thermal_zone_of_add_sensor(struct device_node *zone,
mutex_lock(tzd-lock);
tz-get_temp = get_temp;
tz-get_trend = get_trend;
+ tz-set_emul_temp = set_emul_temp;
tz-sensor_data = data;
tzd-ops-get_temp = of_thermal_get_temp;
tzd-ops-get_trend = of_thermal_get_trend;
+ tzd-ops-set_emul_temp = of_thermal_set_emul_temp;
mutex_unlock(tzd-lock);
return tzd;
@@ -411,7 +426,8 @@ thermal_zone_of_add_sensor(struct device_node *zone,
struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
void *data, int (*get_temp)(void *, long *),
- int (*get_trend)(void *, long *))
+ int (*get_trend)(void *, long *),
+ int (*set_emul_temp)(void *, unsigned long))
{
struct device_node *np, *child, *sensor_np;
@@ -453,7 +469,8 @@ thermal_zone_of_sensor_register(struct device *dev, int
sensor_id,
return thermal_zone_of_add_sensor(child, sensor_np,
data,
get_temp,
- get_trend);
+ get_trend,
+ set_emul_temp);
}
}
of_node_put(np);
@@ -494,9 +511,11 @@ void thermal_zone_of_sensor_unregister(struct device
*dev,
mutex_lock(tzd-lock);
tzd-ops-get_temp = NULL;
tzd-ops-get_trend = NULL;
+ tzd-ops-set_emul_temp = NULL;
tz-get_temp = NULL;
tz-get_trend = NULL;
+ tz-set_emul_temp = NULL;
tz-sensor_data = NULL;
mutex_unlock(tzd-lock);
}
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 0305cde..36010e9 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -290,14 +290,16 @@ struct thermal_genl_event {
struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int id,
void *data, int (*get_temp)(void *, long *),
- int (*get_trend)(void *, long *));
+ int (*get_trend)(void *, long *),
+ int (*set_emul_temp)(void *, unsigned long));
void thermal_zone_of_sensor_unregister(struct device *dev,
struct thermal_zone_device *tz);
#else
static inline struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int id,
[PATCH v6 2/7] arm64: dts: Add initial device tree support for EXYNOS7
From: Naveen Krishna Ch naveenkrishna...@gmail.com
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 Ch naveenkrishna...@gmail.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Thomas Abraham thomas...@samsung.com
Tested-by: Thomas Abraham thomas...@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/Makefile |5 +
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 39 +
arch/arm64/boot/dts/exynos/exynos7.dtsi | 183 +++
4 files changed, 228 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 e8efc8f..fdda246 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,6 +1,7 @@
dts-dirs += apm
dts-dirs += arm
dts-dirs += cavium
+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..c4cabc6
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -0,0 +1,183 @@
+/*
+ * 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;
+ #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 0x100;
+ };
+
+ fin_pll: xxti {
+
[PATCH v6 1/7] arm64: dts: add dt-bindings/ symlink
From: Pankaj Dubey pankaj.du...@samsung.com Add symlink to include/dt-bindings from arch/arm64/boot/dts/include/ to match the ones in ARM architectures so that preprocessed device tree files can include various useful constant definitions. See commit c58299aa8754 (kbuild: create an include chroot for DT bindings) merged in v3.10-rc1 for details. Cc: Catalin Marinas catalin.mari...@arm.com Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Reviewed-by: Thomas Abraham thomas...@samsung.com Tested-by: Thomas Abraham thomas...@samsung.com --- arch/arm64/boot/dts/include/dt-bindings |1 + 1 file changed, 1 insertion(+) create mode 12 arch/arm64/boot/dts/include/dt-bindings diff --git a/arch/arm64/boot/dts/include/dt-bindings b/arch/arm64/boot/dts/include/dt-bindings new file mode 12 index 000..08c00e4 --- /dev/null +++ b/arch/arm64/boot/dts/include/dt-bindings @@ -0,0 +1 @@ +../../../../../include/dt-bindings \ No newline at end of file -- 1.7.9.5 -- 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 v6 0/7] Enable support for Samsung Exynos7 SoC
Exynos7 is a System-On-Chip that is based on 64-bit ARMv8 RISC processor (Cortex-A57). This patchset adds arch/device tree support for Exynos7. These were originally part of 2 patchsets[1][2] adding support for Exynos7. The clock and pinctrl patches are going through the respective maintainer's tree; hence the remaining dt related patches have been consolidated and are being posted here as a separate series. This patchset has build dependencies on the following patches: a] [GIT PULL] Samsung clock changes for 3.19 - specifically the clock dt bindings header. http://comments.gmane.org/gmane.linux.kernel.samsung-soc/39142 b] tty: serial: samsung: Clean-up selection of number of available UARTs http://www.spinics.net/lists/linux-samsung-soc/msg37418.html c] dts, kbuild: Implement support for dtb vendor subdirs(merged in linux-next) https://lkml.org/lkml/2014/10/21/654 [1] arch: arm64: Enable support for Samsung Exynos7 SoC http://www.spinics.net/lists/linux-samsung-soc/msg37047.html [2] Add clock and DT support for a few IPs on Exynos7 http://www.spinics.net/lists/linux-samsung-soc/msg37973.html Abhilash Kesavan (2): arm64: dts: Add PMU DT node for exynos7 SoC arm64: dts: Add nodes for mmc, i2c, rtc, watchdog, adc on Exynos7 Alim Akhtar (2): arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support arm64: Enable Exynos7 SOC in the defconfig Naveen Krishna Ch (2): arm64: dts: Add initial device tree support for EXYNOS7 arm64: dts: Add initial pinctrl support to EXYNOS7 Pankaj Dubey (1): arm64: dts: add dt-bindings/ symlink .../devicetree/bindings/arm/samsung/pmu.txt|1 + arch/arm64/Kconfig | 17 + arch/arm64/boot/dts/Makefile |1 + arch/arm64/boot/dts/exynos/Makefile|5 + arch/arm64/boot/dts/exynos/exynos7-espresso.dts| 84 +++ arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi| 588 arch/arm64/boot/dts/exynos/exynos7.dtsi| 530 ++ arch/arm64/boot/dts/include/dt-bindings|1 + arch/arm64/configs/defconfig |4 + 9 files changed, 1231 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-pinctrl.dtsi create mode 100644 arch/arm64/boot/dts/exynos/exynos7.dtsi create mode 12 arch/arm64/boot/dts/include/dt-bindings -- 1.7.9.5 -- 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 v6 3/7] arm64: dts: Add initial pinctrl support to EXYNOS7
From: Naveen Krishna Ch naveenkrishna...@gmail.com
Add intial pin configuration nodes for EXYNOS7.
Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Thomas Abraham thomas...@samsung.com
Tested-by: Thomas Abraham thomas...@samsung.com
Acked-by: Tomasz Figa tomasz.f...@gmail.com
Cc: Rob Herring r...@kernel.org
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Linus Walleij linus.wall...@linaro.org
---
arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 588 +++
arch/arm64/boot/dts/exynos/exynos7.dtsi | 66 +++
2 files changed, 654 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
new file mode 100644
index 000..2eef4a2
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
@@ -0,0 +1,588 @@
+/*
+ * Samsung's Exynos7 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos7 SoC pin-mux and pin-config options are listed as
+ * device tree nodes in this file.
+ *
+ * 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.
+*/
+
+pinctrl_alive {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ interrupt-parent = gic;
+ #interrupt-cells = 2;
+ interrupts = 0 0 0, 0 1 0, 0 2 0, 0 3 0,
+0 4 0, 0 5 0, 0 6 0, 0 7 0;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ interrupt-parent = gic;
+ #interrupt-cells = 2;
+ interrupts = 0 8 0, 0 9 0, 0 10 0, 0 11 0,
+0 12 0, 0 13 0, 0 14 0, 0 15 0;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpa3: gpa3 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+};
+
+pinctrl_bus0 {
+ gpb0: gpb0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpc0: gpc0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpc1: gpc1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpc2: gpc2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpc3: gpc3 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd0: gpd0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd1: gpd1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd2: gpd2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd4: gpd4 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd5: gpd5 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd6: gpd6 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd7: gpd7 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd8: gpd8 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpg0: gpg0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
[PATCH v6 4/7] arm64: dts: Add PMU DT node for exynos7 SoC
Adds PMU DT node for exynos7 SoC.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
.../devicetree/bindings/arm/samsung/pmu.txt|1 +
arch/arm64/boot/dts/exynos/exynos7.dtsi|5 +
2 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 1e1979b..67b2113 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -10,6 +10,7 @@ Properties:
- samsung,exynos5260-pmu - for Exynos5260 SoC.
- samsung,exynos5410-pmu - for Exynos5410 SoC,
- samsung,exynos5420-pmu - for Exynos5420 SoC.
+ - samsung,exynos7-pmu - for Exynos7 SoC.
second value must be always syscon.
- reg : offset and length of the register set.
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index c38567a..2bce3f3 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -243,6 +243,11 @@
1 11 0xff01,
1 10 0xff01;
};
+
+ pmu_system_controller: system-controller@105c {
+ compatible = samsung,exynos7-pmu, syscon;
+ reg = 0x105c 0x5000;
+ };
};
};
--
1.7.9.5
--
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 v6 6/7] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support
From: Alim Akhtar alim.akh...@samsung.com This patch adds the necessary Kconfig entries to enable support for the ARMv8 based Exynos7 SoC. It also enables RTC, WDT and Pinctrl for Exynos7. Signed-off-by: Alim Akhtar alim.akh...@samsung.com Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Reviewed-by: Thomas Abraham thomas...@samsung.com Tested-by: Thomas Abraham thomas...@samsung.com Cc: Rob Herring r...@kernel.org Cc: Catalin Marinas catalin.mari...@arm.com --- arch/arm64/Kconfig | 17 + 1 file changed, 17 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 66b0b51..8196889 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -148,6 +148,23 @@ config ARCH_THUNDER help This enables support for Cavium's Thunder Family of SoCs. +config ARCH_EXYNOS + bool + help + This enables support for Samsung Exynos SoC family + +config ARCH_EXYNOS7 + bool ARMv8 based Samsung Exynos7 + select ARCH_EXYNOS + select COMMON_CLK_SAMSUNG + select HAVE_S3C2410_WATCHDOG if WATCHDOG + select HAVE_S3C_RTC if RTC_CLASS + select PINCTRL + select PINCTRL_EXYNOS + + help + This enables support for Samsung Exynos7 SoC family + config ARCH_VEXPRESS bool ARMv8 software model (Versatile Express) select ARCH_REQUIRE_GPIOLIB -- 1.7.9.5 -- 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 v6 5/7] arm64: dts: Add nodes for mmc, i2c, rtc, watchdog, adc on Exynos7
Add nodes for 3 mmc channels, 12 i2c channels, rtc, watchdog and adc
on Exynos7.
Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 45
arch/arm64/boot/dts/exynos/exynos7.dtsi | 276 +++
2 files changed, 321 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index e2c8283..5424cc4 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -18,6 +18,8 @@
aliases {
serial0 = serial_2;
+ mshc0 = mmc_0;
+ mshc2 = mmc_2;
};
chosen {
@@ -37,3 +39,46 @@
serial_2 {
status = okay;
};
+
+rtc {
+ status = okay;
+};
+
+watchdog {
+ status = okay;
+};
+
+adc {
+ status = okay;
+};
+
+mmc_0 {
+ status = okay;
+ num-slots = 1;
+ broken-cd;
+ cap-mmc-highspeed;
+ non-removable;
+ card-detect-delay = 200;
+ clock-frequency = 8;
+ samsung,dw-mshc-ciu-div = 3;
+ samsung,dw-mshc-sdr-timing = 0 4;
+ samsung,dw-mshc-ddr-timing = 0 2;
+ pinctrl-names = default;
+ pinctrl-0 = sd0_clk sd0_cmd sd0_qrdy sd0_bus1 sd0_bus4 sd0_bus8;
+ bus-width = 8;
+};
+
+mmc_2 {
+ status = okay;
+ num-slots = 1;
+ cap-sd-highspeed;
+ card-detect-delay = 200;
+ clock-frequency = 4;
+ samsung,dw-mshc-ciu-div = 3;
+ samsung,dw-mshc-sdr-timing = 2 3;
+ samsung,dw-mshc-ddr-timing = 1 2;
+ pinctrl-names = default;
+ pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus1 sd2_bus4;
+ bus-width = 4;
+ disable-wp;
+};
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 2bce3f3..cff0256 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -113,6 +113,27 @@
dout_sclk_mfc_pll;
};
+ clock_top1: clock-controller@105e {
+ compatible = samsung,exynos7-clock-top1;
+ reg = 0x105e 0xb000;
+ #clock-cells = 1;
+ clocks = fin_pll, clock_topc DOUT_SCLK_BUS0_PLL,
+clock_topc DOUT_SCLK_BUS1_PLL,
+clock_topc DOUT_SCLK_CC_PLL,
+clock_topc DOUT_SCLK_MFC_PLL;
+ clock-names = fin_pll, dout_sclk_bus0_pll,
+ dout_sclk_bus1_pll, dout_sclk_cc_pll,
+ dout_sclk_mfc_pll;
+ };
+
+ clock_ccore: clock-controller@105b {
+ compatible = samsung,exynos7-clock-ccore;
+ reg = 0x105b 0xd00;
+ #clock-cells = 1;
+ clocks = fin_pll, clock_topc DOUT_ACLK_CCORE_133;
+ clock-names = fin_pll, dout_aclk_ccore_133;
+ };
+
clock_peric0: clock-controller@1361 {
compatible = samsung,exynos7-clock-peric0;
reg = 0x1361 0xd00;
@@ -143,6 +164,27 @@
clock-names = fin_pll, dout_aclk_peris_66;
};
+ clock_fsys0: clock-controller@10e9 {
+ compatible = samsung,exynos7-clock-fsys0;
+ reg = 0x10e9 0xd00;
+ #clock-cells = 1;
+ clocks = fin_pll, clock_top1 DOUT_ACLK_FSYS0_200,
+clock_top1 DOUT_SCLK_MMC2;
+ clock-names = fin_pll, dout_aclk_fsys0_200,
+ dout_sclk_mmc2;
+ };
+
+ clock_fsys1: clock-controller@156e {
+ compatible = samsung,exynos7-clock-fsys1;
+ reg = 0x156e 0xd00;
+ #clock-cells = 1;
+ clocks = fin_pll, clock_top1 DOUT_ACLK_FSYS1_200,
+clock_top1 DOUT_SCLK_MMC0,
+clock_top1 DOUT_SCLK_MMC1;
+ clock-names = fin_pll, dout_aclk_fsys1_200,
+ dout_sclk_mmc0, dout_sclk_mmc1;
+ };
+
serial_0: serial@1363 {
compatible = samsung,exynos4210-uart;
reg = 0x1363 0x100;
@@ -236,6 +278,162 @@
interrupts = 0 203 0;
};
+ hsi2c_0: hsi2c@1364 {
+ compatible = samsung,exynos7-hsi2c;
+ reg = 0x1364 0x1000;
+ interrupts = 0 441 0;
+
[PATCH v6 7/7] arm64: Enable Exynos7 SOC in the defconfig
From: Alim Akhtar alim.akh...@samsung.com Enable Exynos7 SOC in the arm64 defconfig. Also enable the samsung serial driver needed by this SoC. Signed-off-by: Alim Akhtar alim.akh...@samsung.com Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com --- arch/arm64/configs/defconfig |4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 4ce602c..cc2aa19 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -32,6 +32,8 @@ CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_IOSCHED_DEADLINE is not set +CONFIG_ARCH_EXYNOS=y +CONFIG_ARCH_EXYNOS7=y CONFIG_ARCH_THUNDER=y CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_XGENE=y @@ -84,6 +86,8 @@ CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y +CONFIG_SERIAL_SAMSUNG=y +CONFIG_SERIAL_SAMSUNG_CONSOLE=y CONFIG_SERIAL_OF_PLATFORM=y CONFIG_VIRTIO_CONSOLE=y # CONFIG_HW_RANDOM is not set -- 1.7.9.5 -- 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/4] drm/exynos: fimd: support Exynos4415 SoC
This patch supports Exynos4415 SoC.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/devicetree/bindings/video/samsung-fimd.txt | 1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 +++
2 files changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
b/Documentation/devicetree/bindings/video/samsung-fimd.txt
index 4e6c77c..cf1af63 100644
--- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -11,6 +11,7 @@ Required properties:
samsung,s5pv210-fimd; /* for S5PV210 SoC */
samsung,exynos3250-fimd; /* for Exynos3250/3472 SoCs */
samsung,exynos4210-fimd; /* for Exynos4 SoCs */
+ samsung,exynos4415-fimd; /* for Exynos4415 SoC */
samsung,exynos5250-fimd; /* for Exynos5 SoCs */
- reg: physical base address and length of the FIMD registers set.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 085b066..5dfbbdb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -120,6 +120,15 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
.has_shadowcon = 1,
};
+static struct fimd_driver_data exynos4415_fimd_driver_data = {
+ .timing_base = 0x2,
+ .lcdblk_offset = 0x210,
+ .lcdblk_vt_shift = 10,
+ .lcdblk_bypass_shift = 1,
+ .has_shadowcon = 1,
+ .has_vidoutcon = 1,
+};
+
static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
.lcdblk_offset = 0x214,
@@ -180,6 +189,8 @@ static const struct of_device_id fimd_driver_dt_match[] = {
.data = exynos3_fimd_driver_data },
{ .compatible = samsung,exynos4210-fimd,
.data = exynos4_fimd_driver_data },
+ { .compatible = samsung,exynos4415-fimd,
+ .data = exynos4415_fimd_driver_data },
{ .compatible = samsung,exynos5250-fimd,
.data = exynos5_fimd_driver_data },
{},
--
1.9.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 4/4] ARM: dts: add mipi dsi device node to exynos4415.dtsi
This patch adds mipi dsi device node to exynos4415.dtsi.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4415.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4415.dtsi
b/arch/arm/boot/dts/exynos4415.dtsi
index 30acb3a..6105236 100644
--- a/arch/arm/boot/dts/exynos4415.dtsi
+++ b/arch/arm/boot/dts/exynos4415.dtsi
@@ -246,6 +246,21 @@
status = disabled;
};
+ dsi_0: dsi@11C8 {
+ compatible = samsung,exynos4415-mipi-dsi;
+ reg = 0x11C8 0x1;
+ interrupts = 0 83 0;
+ samsung,phy-type = 0;
+ samsung,power-domain = pd_lcd0;
+ phys = mipi_phy 1;
+ phy-names = dsim;
+ clocks = cmu CLK_DSIM0, cmu CLK_SCLK_MIPI0;
+ clock-names = bus_clk, pll_clk;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
hsotg: hsotg@1248 {
compatible = samsung,s3c6400-hsotg;
reg = 0x1248 0x2;
--
1.9.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 3/4] ARM: dts: add fimd device node to exynos4415.dtsi
This patch adds fimd device node to exynos4415.dtsi.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4415.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4415.dtsi
b/arch/arm/boot/dts/exynos4415.dtsi
index c1c9b37..30acb3a 100644
--- a/arch/arm/boot/dts/exynos4415.dtsi
+++ b/arch/arm/boot/dts/exynos4415.dtsi
@@ -234,6 +234,18 @@
interrupts = 0 240 0;
};
+ fimd: fimd@11C0 {
+ compatible = samsung,exynos4415-fimd;
+ reg = 0x11C0 0x3;
+ interrupt-names = fifo, vsync, lcd_sys;
+ interrupts = 0 84 0, 0 85 0, 0 86 0;
+ clocks = cmu CLK_SCLK_FIMD0, cmu CLK_FIMD0;
+ clock-names = sclk_fimd, fimd;
+ samsung,power-domain = pd_lcd0;
+ samsung,sysreg = sysreg_system_controller;
+ status = disabled;
+ };
+
hsotg: hsotg@1248 {
compatible = samsung,s3c6400-hsotg;
reg = 0x1248 0x2;
--
1.9.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/4] drm/exynos: dsi: support Exynos4415 SoC
This patch supports Exynos4415 SoC.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/devicetree/bindings/video/exynos_dsim.txt | 1 +
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 +++
2 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index e74243b..ca2b4aa 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: value should be one of the following
samsung,exynos3250-mipi-dsi /* for Exynos3250/3472 SoCs */
samsung,exynos4210-mipi-dsi /* for Exynos4 SoCs */
+ samsung,exynos4415-mipi-dsi /* for Exynos4415 SoC */
samsung,exynos5410-mipi-dsi /* for Exynos5410/5420/5440 SoCs
*/
- reg: physical base address and length of the registers set for the device
- interrupts: should contain DSI interrupt
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index acf7e9e..ff17c6e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -316,6 +316,11 @@ static struct exynos_dsi_driver_data
exynos4_dsi_driver_data = {
.has_clklane_stop = 1,
};
+static struct exynos_dsi_driver_data exynos4415_dsi_driver_data = {
+ .plltmr_reg = 0x58,
+ .has_clklane_stop = 1,
+};
+
static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
.plltmr_reg = 0x58,
};
@@ -325,6 +330,8 @@ static struct of_device_id exynos_dsi_of_match[] = {
.data = exynos3_dsi_driver_data },
{ .compatible = samsung,exynos4210-mipi-dsi,
.data = exynos4_dsi_driver_data },
+ { .compatible = samsung,exynos4415-mipi-dsi,
+ .data = exynos4415_dsi_driver_data },
{ .compatible = samsung,exynos5410-mipi-dsi,
.data = exynos5_dsi_driver_data },
{ }
--
1.9.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 0/4] drm/exynos: support Exynos4415 SoC
This patch series adds of_device_id and relevant device nodes for Exynos4415 SoC support. This is based on exynos-drm-next branch for drm/exynos, and is based on for-next branch in linux-samsung git for dts. I think this requires rebase for the patch drm/exynos: add has_vtsel flag[1]. [1] http://www.spinics.net/lists/dri-devel/msg71092.html YoungJun Cho (4): drm/exynos: dsi: support Exynos4415 SoC drm/exynos: fimd: support Exynos4415 SoC ARM: dts: add fimd device node to exynos4415.dtsi ARM: dts: add mipi dsi device node to exynos4415.dtsi .../devicetree/bindings/video/exynos_dsim.txt | 1 + .../devicetree/bindings/video/samsung-fimd.txt | 1 + arch/arm/boot/dts/exynos4415.dtsi | 27 ++ drivers/gpu/drm/exynos/exynos_drm_dsi.c| 7 ++ drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 + 5 files changed, 47 insertions(+) -- 1.9.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: [PATCHv2] pinctrl: exynos: Add support for Exynos4415
Dear Linus,
Could you please review this patch?
Best Regards,
Chanwoo Choi
On 10/27/2014 10:21 AM, Chanwoo Choi wrote:
From: Tomasz Figa tomasz.f...@gmail.com
The pin controllers of Exynos4415 are similar to Exynos4412, but certain
differences cause the need to create separate driver data for it. This
patch adds pin controller and bank descriptor arrays to the driver to
support the new SoC.
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Thomas Abraham thomas.abra...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
[cw00.choi: Rebase it on mainline kernel]
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changes from v1:
- Separate only pinctrl patch from Exynos4415 patchset[1]
[1] [PATCH 0/5] Support new Exynos4415 SoC based on Cortex-A9 quad cores
: https://lkml.org/lkml/2014/10/19/253
drivers/pinctrl/samsung/pinctrl-exynos.c | 78 +++
drivers/pinctrl/samsung/pinctrl-samsung.c | 2 +
drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
3 files changed, 81 insertions(+)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index d7154ed..065eee0 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -920,6 +920,84 @@ struct samsung_pin_ctrl exynos4x12_pin_ctrl[] = {
},
};
+/* pin banks of exynos4415 pin-controller 0 */
+static struct samsung_pin_bank exynos4415_pin_banks0[] = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x000, gpa0, 0x00),
+ EXYNOS_PIN_BANK_EINTG(6, 0x020, gpa1, 0x04),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, gpb, 0x08),
+ EXYNOS_PIN_BANK_EINTG(5, 0x060, gpc0, 0x0c),
+ EXYNOS_PIN_BANK_EINTG(5, 0x080, gpc1, 0x10),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0A0, gpd0, 0x14),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0C0, gpd1, 0x18),
+ EXYNOS_PIN_BANK_EINTG(8, 0x180, gpf0, 0x30),
+ EXYNOS_PIN_BANK_EINTG(8, 0x1A0, gpf1, 0x34),
+ EXYNOS_PIN_BANK_EINTG(1, 0x1C0, gpf2, 0x38),
+};
+
+/* pin banks of exynos4415 pin-controller 1 */
+static struct samsung_pin_bank exynos4415_pin_banks1[] = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, gpk0, 0x08),
+ EXYNOS_PIN_BANK_EINTG(7, 0x060, gpk1, 0x0c),
+ EXYNOS_PIN_BANK_EINTG(7, 0x080, gpk2, 0x10),
+ EXYNOS_PIN_BANK_EINTG(7, 0x0A0, gpk3, 0x14),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0C0, gpl0, 0x18),
+ EXYNOS_PIN_BANK_EINTN(6, 0x120, mp00),
+ EXYNOS_PIN_BANK_EINTN(4, 0x140, mp01),
+ EXYNOS_PIN_BANK_EINTN(6, 0x160, mp02),
+ EXYNOS_PIN_BANK_EINTN(8, 0x180, mp03),
+ EXYNOS_PIN_BANK_EINTN(8, 0x1A0, mp04),
+ EXYNOS_PIN_BANK_EINTN(8, 0x1C0, mp05),
+ EXYNOS_PIN_BANK_EINTN(8, 0x1E0, mp06),
+ EXYNOS_PIN_BANK_EINTG(8, 0x260, gpm0, 0x24),
+ EXYNOS_PIN_BANK_EINTG(7, 0x280, gpm1, 0x28),
+ EXYNOS_PIN_BANK_EINTG(5, 0x2A0, gpm2, 0x2c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x2C0, gpm3, 0x30),
+ EXYNOS_PIN_BANK_EINTG(8, 0x2E0, gpm4, 0x34),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC00, gpx0, 0x00),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC20, gpx1, 0x04),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC40, gpx2, 0x08),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC60, gpx3, 0x0c),
+};
+
+/* pin banks of exynos4415 pin-controller 2 */
+static struct samsung_pin_bank exynos4415_pin_banks2[] = {
+ EXYNOS_PIN_BANK_EINTG(7, 0x000, gpz, 0x00),
+ EXYNOS_PIN_BANK_EINTN(2, 0x000, etc1),
+};
+
+/*
+ * Samsung pinctrl driver data for Exynos4415 SoC. Exynos4415 SoC includes
+ * three gpio/pin-mux/pinconfig controllers.
+ */
+struct samsung_pin_ctrl exynos4415_pin_ctrl[] = {
+ {
+ /* pin-controller instance 0 data */
+ .pin_banks = exynos4415_pin_banks0,
+ .nr_banks = ARRAY_SIZE(exynos4415_pin_banks0),
+ .eint_gpio_init = exynos_eint_gpio_init,
+ .suspend= exynos_pinctrl_suspend,
+ .resume = exynos_pinctrl_resume,
+ .label = exynos4415-gpio-ctrl0,
+ }, {
+ /* pin-controller instance 1 data */
+ .pin_banks = exynos4415_pin_banks1,
+ .nr_banks = ARRAY_SIZE(exynos4415_pin_banks1),
+ .eint_gpio_init = exynos_eint_gpio_init,
+ .eint_wkup_init = exynos_eint_wkup_init,
+ .suspend= exynos_pinctrl_suspend,
+ .resume = exynos_pinctrl_resume,
+ .label = exynos4415-gpio-ctrl1,
+ }, {
+ /* pin-controller instance 2 data */
+ .pin_banks = exynos4415_pin_banks2,
+ .nr_banks = ARRAY_SIZE(exynos4415_pin_banks2),
+ .eint_gpio_init = exynos_eint_gpio_init,
+ .suspend= exynos_pinctrl_suspend,
+ .resume = exynos_pinctrl_resume,
+ .label = exynos4415-gpio-ctrl2,
+ },
+};
+
/* pin
Re: [PATCHv2] pinctrl: exynos: Add support for Exynos4415
Hi Chanwoo, 2014-11-07 15:23 GMT+09:00 Chanwoo Choi cw00.c...@samsung.com: Dear Linus, Could you please review this patch? I'll take care of this during this weekend. Sorry for all the delays, but I was in the middle of relocation to another country and I just didn't have enough time yet to collect all the patches. 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 0/2] add support for exynos7 I2S controller
I2S on exynos7 includes the below changes - has got support for lower root clock sampling frequencies like 64, 128, 96, 192fs. I2S on previous SoCs supports only 256,512,384 and 768. - supports 7.1CH TDM mode for recording. exynos5 has only 7.1CH TDM mode for playback. - secondary dai works with only external DMA. on previous SoCs secondary dai can work with either both or only internal DMA. - I2S1 controller upgraded to 5.1CH with slighlty modified bit offsets for supporting lower RFS and more no.of BFS values. As internal dma is not mandatory on all SoCs this patchset introduced a quirk for the same and added a structure to hold all the modified bit offsets across all SoCs. This patchset is made based on linux-next master branch and tested with exynos7 base support from the below link. http://www.spinics.net/lists/linux-samsung-soc/msg37047.html Padmavathi Venna (2): ASoC: Samsung: Add quirk for internal DMA ASoC: samsung: add support for exynos7 I2S controller .../devicetree/bindings/sound/samsung-i2s.txt | 15 +- include/linux/platform_data/asoc-s3c.h |1 + sound/soc/samsung/Kconfig |2 +- sound/soc/samsung/i2s-regs.h | 10 +- sound/soc/samsung/i2s.c| 228 ++-- 5 files changed, 180 insertions(+), 76 deletions(-) -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ASoC: Samsung: Add quirk for internal DMA
Internal DMA is available only on some of Samsung platforms.
So added a quirk for the same and made it optional.
Signed-off-by: Padmavathi Venna padm...@samsung.com
---
include/linux/platform_data/asoc-s3c.h |1 +
sound/soc/samsung/i2s.c| 12 ++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/include/linux/platform_data/asoc-s3c.h
b/include/linux/platform_data/asoc-s3c.h
index a6591c6..5e0bc77 100644
--- a/include/linux/platform_data/asoc-s3c.h
+++ b/include/linux/platform_data/asoc-s3c.h
@@ -27,6 +27,7 @@ struct samsung_i2s {
#define QUIRK_NO_MUXPSR(1 2)
#define QUIRK_NEED_RSTCLR (1 3)
#define QUIRK_SUPPORTS_TDM (1 4)
+#define QUIRK_SUPPORTS_IDMA(1 5)
/* Quirks of the I2S controller */
u32 quirks;
dma_addr_t idma_addr;
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 9d51347..38b9a52 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -987,7 +987,7 @@ static int samsung_i2s_dai_probe(struct snd_soc_dai *dai)
if (i2s-quirks QUIRK_NEED_RSTCLR)
writel(CON_RSTCLR, i2s-addr + I2SCON);
- if (i2s-quirks QUIRK_SEC_DAI)
+ if (i2s-quirks QUIRK_SUPPORTS_IDMA)
idma_reg_addr_init(i2s-addr,
i2s-sec_dai-idma_playback.dma_addr);
@@ -1199,10 +1199,9 @@ static int samsung_i2s_probe(struct platform_device
*pdev)
quirks = i2s_dai_data-quirks;
if (of_property_read_u32(np, samsung,idma-addr,
idma_addr)) {
- if (quirks QUIRK_SEC_DAI) {
- dev_err(pdev-dev, idma address is not\
+ if (quirks QUIRK_SUPPORTS_IDMA) {
+ dev_info(pdev-dev, idma address is not\
specified);
- return -EINVAL;
}
}
}
@@ -1309,13 +1308,14 @@ static const struct samsung_i2s_dai_data i2sv3_dai_type
= {
static const struct samsung_i2s_dai_data i2sv5_dai_type = {
.dai_type = TYPE_PRI,
- .quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR,
+ .quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
+ QUIRK_SUPPORTS_IDMA,
};
static const struct samsung_i2s_dai_data i2sv6_dai_type = {
.dai_type = TYPE_PRI,
.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
- QUIRK_SUPPORTS_TDM,
+ QUIRK_SUPPORTS_TDM | QUIRK_SUPPORTS_IDMA,
};
static const struct samsung_i2s_dai_data samsung_dai_type_pri = {
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ASoC: samsung: add support for exynos7 I2S controller
Exynos7 I2S controller has no internal dma, supports more
no. of root clock sampling frequencies and has more no.of Rx
fifos to support 7.1CH recording in TDM mode. Due to more no.
of root clock frequency values some of the bit offsets got
shifted up by one. Also I2S1 on previous Samsung platforms
uses v3 dai type but on Exynos7 it is upgraded to v5 with
slightly modified register offsets for supporting more no.of
RFS values. Due to the above changes, the driver has to be
modified to handle all versions of I2S controller. For this
I introduced a new structure to hold modified bit offsets and
masks which is passed as dai data.
Signed-off-by: Padmavathi Venna padm...@samsung.com
---
.../devicetree/bindings/sound/samsung-i2s.txt | 15 +-
sound/soc/samsung/Kconfig |2 +-
sound/soc/samsung/i2s-regs.h | 10 +-
sound/soc/samsung/i2s.c| 218 ++--
4 files changed, 174 insertions(+), 71 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
index 7386d44..d188296 100644
--- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
@@ -6,10 +6,17 @@ Required SoC Specific Properties:
- samsung,s3c6410-i2s: for 8/16/24bit stereo I2S.
- samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with
secondary fifo, s/w reset control and internal mux for root clk src.
- - samsung,exynos5420-i2s: for 8/16/24bit multichannel(7.1) I2S with
- secondary fifo, s/w reset control, internal mux for root clk src and
- TDM support. TDM (Time division multiplexing) is to allow transfer of
- multiple channel audio data on single data line.
+ - samsung,exynos5420-i2s: for 8/16/24bit multichannel(5.1) I2S for
+ playback, sterio channel capture, secondary fifo using internal
+ or external dma, s/w reset control, internal mux for root clk src
+ and 7.1 channel TDM support for playback. TDM (Time division multiplexing)
+ is to allow transfer of multiple channel audio data on single data line.
+ - samsung,exynos7-i2s: with all the available features of exynos5 i2s,
+ exynos7 I2S has 7.1 channel TDM support for capture, secondary fifo
+ with only external dma and more no.of root clk sampling frequencies.
+ - samsung,exynos7-i2s1: I2S1 on previous samsung platforms supports
+ stereo channels. exynos7 i2s1 upgraded to 5.1 multichannel with
+ slightly modified bit offsets.
- reg: physical base address of the controller and length of memory mapped
region.
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 55a3869..e0e737f 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -1,6 +1,6 @@
config SND_SOC_SAMSUNG
tristate ASoC support for Samsung
- depends on PLAT_SAMSUNG
+ depends on (PLAT_SAMSUNG || ARCH_EXYNOS)
depends on S3C64XX_PL080 || !ARCH_S3C64XX
depends on S3C24XX_DMAC || !ARCH_S3C24XX
select SND_SOC_GENERIC_DMAENGINE_PCM
diff --git a/sound/soc/samsung/i2s-regs.h b/sound/soc/samsung/i2s-regs.h
index 821a502..9170c31 100644
--- a/sound/soc/samsung/i2s-regs.h
+++ b/sound/soc/samsung/i2s-regs.h
@@ -33,8 +33,9 @@
#define I2SLVL3ADDR0x3c
#define I2SSTR10x40
#define I2SVER 0x44
-#define I2SFIC20x48
+#define I2SFIC10x48
#define I2STDM 0x4c
+#define I2SFSTA0x50
#define CON_RSTCLR (1 31)
#define CON_FRXOFSTATUS(1 26)
@@ -93,8 +94,6 @@
#define MOD_BLC_24BIT (2 13)
#define MOD_BLC_MASK (3 13)
-#define MOD_IMS_SYSMUX (1 10)
-#define MOD_SLAVE (1 11)
#define MOD_TXONLY (0 8)
#define MOD_RXONLY (1 8)
#define MOD_TXRX (2 8)
@@ -132,7 +131,10 @@
#define EXYNOS5420_MOD_BCLK_256FS 8
#define EXYNOS5420_MOD_BCLK_MASK 0xf
-#define MOD_CDCLKCON (1 12)
+#define EXYNOS7_MOD_RCLK_64FS 4
+#define EXYNOS7_MOD_RCLK_128FS 5
+#define EXYNOS7_MOD_RCLK_96FS 6
+#define EXYNOS7_MOD_RCLK_192FS 7
#define PSR_PSREN (1 15)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 38b9a52..947352d 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -36,9 +36,24 @@ enum samsung_dai_type {
TYPE_SEC,
};
+struct samsung_i2s_variant_regs {
+ unsigned intbfs_off;
+ unsigned intrfs_off;
+ unsigned intsdf_off;
+ unsigned inttxr_off;
+ unsigned intrclksrc_off;
+ unsigned intmss_off;
+ unsigned intcdclkcon_off;
+ unsigned intlrp_off;
+ unsigned intbfs_mask;
+ unsigned intrfs_mask;
+ unsigned intftx0cnt_off;
+};
+
struct samsung_i2s_dai_data {
int dai_type;
