* Re: [PATCH v2 3/4] arm64: arch_timer: Work around Erratum Hisilicon-161601
From: Will Deacon @ 2016-10-28 16:00 UTC (permalink / raw)
To: Ding Tianhong
Cc: catalin.marinas-5wv7dgnIgG8, marc.zyngier-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, oss-fOR+EgIDQEHk1uMJSBkQmQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, stuart.yoder-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxarm-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <1477553651-13428-3-git-send-email-dingtianhong-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Hi Ding,
On Thu, Oct 27, 2016 at 03:34:10PM +0800, Ding Tianhong wrote:
> Erratum Hisilicon-161601 says that the ARM generic timer counter "has the
> potential to contain an erroneous value when the timer value changes".
> Accesses to TVAL (both read and write) are also affected due to the implicit counter
> read. Accesses to CVAL are not affected.
>
> The workaround is to reread the system count registers until the value of the second
> read is larger than the first one by less than 32, the system counter can be guaranteed
> not to return wrong value twice by back-to-back read and the error value is always larger
> than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL.
>
> The workaround is enabled if the hisilicon,erratum-161601 property is found in
> the timer node in the device tree. This can be overridden with the
> clocksource.arm_arch_timer.hisilicon-161601 boot parameter, which allows KVM
> users to enable the workaround until a mechanism is implemented to
> automatically communicate this information.
>
> Fix some description for fsl erratum a008585.
>
> v2: Significant rework based on feedback, including seperate the fsl erratum a008585
> to another patch, update the erratum name and remove unwanted code.
>
> Signed-off-by: Ding Tianhong <dingtianhong-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> ---
[...]
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 8a753fd..4aafb6a 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -312,8 +312,20 @@ config FSL_ERRATUM_A008585
> help
> This option enables a workaround for Freescale/NXP Erratum
> A-008585 ("ARM generic timer may contain an erroneous
> - value"). The workaround will only be active if the
> + value"). The workaround will be active if the
> fsl,erratum-a008585 property is found in the timer node.
> + This can be overridden with the clocksource.arm_arch_timer.fsl-a008585
> + boot parameter.
> +
> +config HISILICON_ERRATUM_161601
> + bool "Workaround for Hisilicon Erratum 161601"
> + default y
> + depends on ARM_ARCH_TIMER && ARM64
> + help
> + This option enables a workaround for Hisilicon Erratum
> + 161601. The workaround will be active if the hisilicon,erratum-161601
> + property is found in the timer node. This can be overridden with
> + the clocksource.arm_arch_timer.hisilicon-161601 boot parameter.
I'm really not keen on having a kernel commandline parameter for this.
It's not something we've done for other, similar errata (e.g. CNTFRQ
reporting the wrong value) and I think it's a slippery slope to having
more of these workarounds controlled at boot-time. If you have a board
that is affected by this, it's always going to need the workaround. Why
would you turn it off?
Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] mmc: sdhci: Use sdhci-caps-mask and sdhci-caps to change the caps read during __sdhci_read_caps
From: Zach Brown @ 2016-10-28 15:56 UTC (permalink / raw)
To: ulf.hansson
Cc: adrian.hunter, robh+dt, mark.rutland, linux-mmc, devicetree,
linux-kernel, zach.brown
In-Reply-To: <1477670171-30015-1-git-send-email-zach.brown@ni.com>
The sdhci capabilities register can be incorrect. The sdhci-caps-mask
and sdhci-caps dt properties specify which bits of the register are
incorrect and what their values should be. This patch makes the sdhci
driver use those properties to correct the caps during
__sdhci_read_caps.
During __sdhci_read_caps
Use the sdhci-caps-mask property to turn off the incorrect bits of the
sdhci register after reading them.
Use the sdhci-caps to turn on bits after using sdhci-caps-mask to turn
off the incorrect ones.
Signed-off-by: Zach Brown <zach.brown@ni.com>
---
drivers/mmc/host/sdhci.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1e25b01..d5feae4 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -22,6 +22,7 @@
#include <linux/scatterlist.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
+#include <linux/of.h>
#include <linux/leds.h>
@@ -2991,6 +2992,8 @@ static int sdhci_set_dma_mask(struct sdhci_host *host)
void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, u32 *caps, u32 *caps1)
{
u16 v;
+ u64 dt_caps_mask = 0;
+ u64 dt_caps = 0;
if (host->read_caps)
return;
@@ -3005,18 +3008,35 @@ void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, u32 *caps, u32 *caps1)
sdhci_do_reset(host, SDHCI_RESET_ALL);
+ of_property_read_u64(mmc_dev(host->mmc)->of_node,
+ "sdhci-caps-mask", &dt_caps_mask);
+ of_property_read_u64(mmc_dev(host->mmc)->of_node,
+ "sdhci-caps", &dt_caps);
+
v = ver ? *ver : sdhci_readw(host, SDHCI_HOST_VERSION);
host->version = (v & SDHCI_SPEC_VER_MASK) >> SDHCI_SPEC_VER_SHIFT;
if (host->quirks & SDHCI_QUIRK_MISSING_CAPS)
return;
- host->caps = caps ? *caps : sdhci_readl(host, SDHCI_CAPABILITIES);
+ if (caps)
+ host->caps = *caps;
+ else {
+ host->caps = sdhci_readl(host, SDHCI_CAPABILITIES);
+ host->caps &= ~lower_32_bits(dt_caps_mask);
+ host->caps |= lower_32_bits(dt_caps);
+ }
if (host->version < SDHCI_SPEC_300)
return;
- host->caps1 = caps1 ? *caps1 : sdhci_readl(host, SDHCI_CAPABILITIES_1);
+ if (caps1)
+ host->caps1 = *caps1;
+ else {
+ host->caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+ host->caps1 &= ~upper_32_bits(dt_caps_mask);
+ host->caps1 |= upper_32_bits(dt_caps);
+ }
}
EXPORT_SYMBOL_GPL(__sdhci_read_caps);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] mmc: sdhci: dt: Add device tree properties sdhci-caps and sdhci-caps-mask
From: Zach Brown @ 2016-10-28 15:56 UTC (permalink / raw)
To: ulf.hansson
Cc: adrian.hunter, robh+dt, mark.rutland, linux-mmc, devicetree,
linux-kernel, zach.brown
In-Reply-To: <1477670171-30015-1-git-send-email-zach.brown@ni.com>
On some systems the sdhci capabilty register is incorrect for one
reason or another.
The sdhci-caps-mask property specifies which bits in the register
are incorrect and should be turned off before using sdhci-caps to turn
on bits.
The sdhci-caps property specifies which bits should be turned on.
Signed-off-by: Zach Brown <zach.brown@ni.com>
---
Documentation/devicetree/bindings/mmc/sdhci.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci.txt
diff --git a/Documentation/devicetree/bindings/mmc/sdhci.txt b/Documentation/devicetree/bindings/mmc/sdhci.txt
new file mode 100644
index 0000000..0f4f1bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci.txt
@@ -0,0 +1,14 @@
+The properties specific for SD host controllers. For properties shared by MMC
+host controllers refer to the mmc[1] bindings.
+
+ [1] Documentation/devicetree/bindings/mmc/mmc.txt
+
+Optional properties:
+- sdhci-caps-mask: The sdhci capabilities register is incorrect. This 64bit
+ property corresponds to the bits in the sdhci capabilty register. If the bit
+ is on in the mask then the bit is incorrect in the register and should be
+ turned off, before applying sdhci-caps.
+- sdhci-caps: The sdhci capabilities register is incorrect. This 64bit
+ property corresponds to the bits in the sdhci capability register. If the
+ bit is on in the property then the bit should be turned on.
+
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] mmc: sdhci: Fix sdhci caps register bits with corrections provided by dt
From: Zach Brown @ 2016-10-28 15:56 UTC (permalink / raw)
To: ulf.hansson
Cc: adrian.hunter, robh+dt, mark.rutland, linux-mmc, devicetree,
linux-kernel, zach.brown
For various reasons the sdhci caps register can be incorrect. This patch set
introduces a general way to correct the bits when they are read to accurately
reflect the capabilties of the controller/board combo.
The first patch creates sdhci-caps and sdhci-caps-mask dt properties that
combined represent the correction to the sdhci caps register.
The second patch uses the new dt properties to correct the caps from the
register as they read during __sdhci_read_caps.
Changes from RFC:
* /s/registers/register
* Moved sdhci dt properties into new documentation file sdhci.txt
Zach Brown (2):
mmc: sdhci: dt: Add device tree properties sdhci-caps and
sdhci-caps-mask
mmc: sdhci: Use sdhci-caps-mask and sdhci-caps to change the caps read
during __sdhci_read_caps
Documentation/devicetree/bindings/mmc/sdhci.txt | 14 ++++++++++++++
drivers/mmc/host/sdhci.c | 24 ++++++++++++++++++++++--
2 files changed, 36 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci.txt
--
2.7.4
^ permalink raw reply
* Re: [PATCH v12 RESEND 0/4] generic TEE subsystem
From: Andrew F. Davis @ 2016-10-28 15:43 UTC (permalink / raw)
To: Jens Wiklander, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Greg Kroah-Hartman, Al Viro,
valentin.manea-hv44wF8Li93QT0dZR+AlfA,
jean-michel.delorme-qxv4g6HH51o, emmanuel.michel-qxv4g6HH51o,
javier-5MUHepqpBA1BDgjK7y7TUQ, Jason Gunthorpe, Mark Rutland,
Michal Simek, Rob Herring, Will Deacon, Arnd Bergmann,
Nishanth Menon, broonie-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1477649984-16777-1-git-send-email-jens.wiklander-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 10/28/2016 05:19 AM, Jens Wiklander wrote:
> Hi,
>
> This patch set introduces a generic TEE subsystem. The TEE subsystem will
> contain drivers for various TEE implementations. A TEE (Trusted Execution
> Environment) is a trusted OS running in some secure environment, for
> example, TrustZone on ARM CPUs, or a separate secure co-processor etc.
>
> Regarding use cases, TrustZone has traditionally been used for
> offloading secure tasks to the secure world. Examples include:
> - Secure key handling where the OS may or may not have direct access to key
> material.
> - E-commerce and payment technologies. Credentials, credit card numbers etc
> could be stored in a more secure environment.
> - Trusted User Interface (TUI) to ensure that no-one can snoop PIN-codes
> etc.
> - Secure boot to ensure that loaded binaries haven’t been tampered with.
> It’s not strictly needed for secure boot, but you could enhance security
> by leveraging a TEE during boot.
> - Digital Rights Management (DRM), the studios provides content with
> different resolution depending on the security of the device. Higher
> security means higher resolution.
>
> A TEE could also be used in existing and new technologies. For example IMA
> (Integrity Measurement Architecture) which has been in the kernel for quite
> a while. Today you can enhance security by using a TPM-chip to sign the IMA
> measurement list. This is something that you also could do by leveraging a
> TEE.
>
> Another example could be in 2-factor authentication which is becoming
> increasingly more important. FIDO (https://fidoalliance.org) for example
> are using public key cryptography in their 2-factor authentication standard
> (U2F). With FIDO, a private and public key pair will be generated for every
> site you visit and the private key should never leave the local device.
> This is an example where you could use secure storage in a TEE for the
> private key.
>
> Today you will find a quite a few different out of tree implementations of
> TEE drivers which tends to fragment the TEE ecosystem and development. We
> think it would be a good idea to have a generic TEE driver integrated in
> the kernel which would serve as a base for several different TEE solutions,
> no matter if they are on-chip like TrustZone or if they are on a separate
> crypto co-processor.
>
> To develop this TEE subsystem we have been using the open source TEE called
> OP-TEE (https://github.com/OP-TEE/optee_os) and therefore this would be the
> first TEE solution supported by this new subsystem. OP-TEE is a
> GlobalPlatform compliant TEE, however this TEE subsystem is not limited to
> only GlobalPlatform TEEs, instead we have tried to design it so that it
> should work with other TEE solutions also.
>
The above is my biggest concern with this whole subsystem, to me it
still feels very OPTEE specific. As much as I would love to believe
OPTEE will be the end-all TEE, I'm sure we soon will start to see wider
use of vendor TEEs (like TI's own legacy Trustzone thing we are hoping
to depreciate with OPTEE moving forward), possibly Google's Trusty TEE,
and whatever Intel/AMD are cooking up for x86.
As we all know when things are upstreamed we lose the ability to make
radical changes easily, especially to full subsystems. What happens when
this framework, built with only one existing TEE, built by the one
existing TEE's devs, is not as flexible as we need when other TEEs start
rolling out?
Do we see this as a chicken and egg situation, or is there any harm
beyond the pains of supporting an out-of-tree driver for a while, to
wait until we have at least one other TEE to add to this subsystem
before merging?
This may also help with the perceived lack of reviewers for this series.
Thanks,
Andrew
> "tee: generic TEE subsystem" brings in the generic TEE subsystem which
> helps when writing a driver for a specific TEE, for example, OP-TEE.
>
> "tee: add OP-TEE driver" is an OP-TEE driver which uses the subsystem to do
> its work.
>
> This patch set has been prepared in cooperation with Javier González who
> proposed "Generic TrustZone Driver in Linux Kernel" patches 28 Nov 2014,
> https://lwn.net/Articles/623380/ . We've since then changed the scope to
> TEE instead of TrustZone.
>
> We have discussed the design on tee-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org (archive at
> https://lists.linaro.org/pipermail/tee-dev/) with people from other
> companies, including Valentin Manea <valentin.manea-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
> Emmanuel MICHEL <emmanuel.michel-qxv4g6HH51o@public.gmane.org>,
> Jean-michel DELORME <jean-michel.delorme-qxv4g6HH51o@public.gmane.org>,
> and Joakim Bech <joakim.bech-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>. Our main concern has been to
> agree on something that is generic enough to support many different
> TEEs while still keeping the interface together.
>
> v12-resend:
> * Rebased on v4.9-rc2
>
> v12:
> * Rebased on v4.8-rc5
> * Addressed review comments from Andrew F. Davis
> * Removed Acked-by: Andreas Dannenberg <dannenberg-l0cyMroinI0@public.gmane.org> as the
> mail bounces
> * Bugfix possible null dereference in error cleanup path of
> optee_probe().
> * Bugfix optee_from_msg_param() when calculating offset of memref
> into a shared memory object
>
> v11:
> * Rebased on v4.8-rc3
> * Addressed review comments from Nishanth Menon
> * Made the TEE framework available as a loadable module.
> * Reviewed-by: Javier González <javier-5MUHepqpBA1BDgjK7y7TUQ@public.gmane.org>
> * Zeroes shared memory on allocation to avoid information leakage
> * Links shared memory objects to context to avoid stealing of shared memory
> object from an unrelated process
> * Allow RPC interruption if supplicant is unavailable
>
> v10:
> * Rebased on v4.7-rc1
> * Addressed private review comments from Nishanth Menon
> * Optee driver only accepts one supplicant process on the privileged device
> * Optee driver avoids long delayed releases of shm objects
> * Added more comments on functions and structs
>
> v9:
> * Rebased on v4.6-rc1
> * Acked-by: Andreas Dannenberg <dannenberg-l0cyMroinI0@public.gmane.org>
> * Addressed comments from Al Viro how file descriptors are passed to
> user space
> * Addressed comments from Randy Dunlap on documentation
> * Changed license for include/uapi/linux/tee.h
>
> v8:
> * Rebased on v4.5-rc3
> * dt/bindings: add bindings for optee
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> * Fixes build error for X86
> * Fixes spell error in "dt/bindings: add bindings for optee"
>
> v7:
> * Rebased on v4.5-rc2
> * Moved the ARM SMC Calling Convention support into a separate patch
> set, which is now merged
>
> v6:
> * Rebased on v4.3-rc7
> * Changed smccc interface to let the compiler marshal most of the
> parameters
> * Added ARCH64 capability for smccc interface
> * Changed the PSCI firmware calls (both arm and arm64) to use the new
> generic smccc interface instead instead of own assembly functions.
> * Move optee DT bindings to below arm/firmware
> * Defines method for OP-TEE driver to call secure world in DT, smc or hvc
> * Exposes implementation id of a TEE driver in sysfs
> to easily spawn corresponding tee-supplicant when device is ready
> * Update OP-TEE Message Protocol to better cope with fragmented physical
> memory
> * Read time directly from OP-TEE driver instead of forwarding the RPC
> request to tee-supplicant
>
> v5:
> * Replaced kref reference counting for the device with a size_t instead as
> the counter is always protected by a mutex
>
> v4:
> * Rebased on 4.1
> * Redesigned the synchronization around entry exit of normal SMC
> * Replaced rwsem on the driver instance with kref and completion since
> rwsem wasn't intended to be used in this way
> * Expanded the TEE_IOCTL_PARAM_ATTR_TYPE_MASK to make room for
> future additional parameter types
> * Documents TEE subsystem and OP-TEE driver
> * Replaced TEE_IOC_CMD with TEE_IOC_OPEN_SESSION, TEE_IOC_INVOKE,
> TEE_IOC_CANCEL and TEE_IOC_CLOSE_SESSION
> * DT bindings in a separate patch
> * Assembly parts moved to arch/arm and arch/arm64 respectively, in a
> separate patch
> * Redefined/clarified the meaning of OPTEE_SMC_SHM_CACHED
> * Removed CMA usage to limit the scope of the patch set
>
> v3:
> * Rebased on 4.1-rc3 (dma_buf_export() API change)
> * A couple of small sparse fixes
> * Documents bindings for OP-TEE driver
> * Updated MAINTAINERS
>
> v2:
> * Replaced the stubbed OP-TEE driver with a real OP-TEE driver
> * Removed most APIs not needed by OP-TEE in current state
> * Update Documentation/ioctl/ioctl-number.txt with correct path to tee.h
> * Rename tee_shm_pool_alloc_cma() to tee_shm_pool_alloc()
> * Moved tee.h into include/uapi/linux/
> * Redefined tee.h IOCTL macros to be directly based on _IOR and friends
> * Removed version info on the API to user space, a data blob which
> can contain an UUID is left for user space to be able to tell which
> protocol to use in TEE_IOC_CMD
> * Changed user space exposed structures to only have types with __ prefix
> * Dropped THIS_MODULE from tee_fops
> * Reworked how the driver is registered and ref counted:
> - moved from using an embedded struct miscdevice to an embedded struct
> device.
> - uses an struct rw_semaphore as synchronization for driver detachment
> - uses alloc/register pattern from TPM
>
> Thanks,
> Jens
>
> Jens Wiklander (4):
> dt/bindings: add bindings for optee
> tee: generic TEE subsystem
> tee: add OP-TEE driver
> Documentation: tee subsystem and op-tee driver
>
> Documentation/00-INDEX | 2 +
> .../bindings/arm/firmware/linaro,optee-tz.txt | 31 +
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> Documentation/ioctl/ioctl-number.txt | 1 +
> Documentation/tee.txt | 118 +++
> MAINTAINERS | 13 +
> drivers/Kconfig | 2 +
> drivers/Makefile | 1 +
> drivers/tee/Kconfig | 18 +
> drivers/tee/Makefile | 5 +
> drivers/tee/optee/Kconfig | 7 +
> drivers/tee/optee/Makefile | 5 +
> drivers/tee/optee/call.c | 435 ++++++++++
> drivers/tee/optee/core.c | 598 ++++++++++++++
> drivers/tee/optee/optee_msg.h | 435 ++++++++++
> drivers/tee/optee/optee_private.h | 185 +++++
> drivers/tee/optee/optee_smc.h | 446 ++++++++++
> drivers/tee/optee/rpc.c | 404 +++++++++
> drivers/tee/optee/supp.c | 273 +++++++
> drivers/tee/tee_core.c | 901 +++++++++++++++++++++
> drivers/tee/tee_private.h | 129 +++
> drivers/tee/tee_shm.c | 357 ++++++++
> drivers/tee/tee_shm_pool.c | 158 ++++
> include/linux/tee_drv.h | 278 +++++++
> include/uapi/linux/tee.h | 403 +++++++++
> 25 files changed, 5206 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> create mode 100644 Documentation/tee.txt
> create mode 100644 drivers/tee/Kconfig
> create mode 100644 drivers/tee/Makefile
> create mode 100644 drivers/tee/optee/Kconfig
> create mode 100644 drivers/tee/optee/Makefile
> create mode 100644 drivers/tee/optee/call.c
> create mode 100644 drivers/tee/optee/core.c
> create mode 100644 drivers/tee/optee/optee_msg.h
> create mode 100644 drivers/tee/optee/optee_private.h
> create mode 100644 drivers/tee/optee/optee_smc.h
> create mode 100644 drivers/tee/optee/rpc.c
> create mode 100644 drivers/tee/optee/supp.c
> create mode 100644 drivers/tee/tee_core.c
> create mode 100644 drivers/tee/tee_private.h
> create mode 100644 drivers/tee/tee_shm.c
> create mode 100644 drivers/tee/tee_shm_pool.c
> create mode 100644 include/linux/tee_drv.h
> create mode 100644 include/uapi/linux/tee.h
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: specifying order of /dev/mmcblk devices via device-tree?
From: Mark Rutland @ 2016-10-28 15:37 UTC (permalink / raw)
To: Tim Harvey
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAJ+vNU1g8nQedd06LeaD10YWUQ_UmdRToUMFKaTNT1aNY56b0g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote:
> Greetings,
>
> I have an IMX6 board that has the following:
> sdhc1: mmc0: sdio radio
> sdhc2: mmc1: /dev/mmcblk1: microSD connector
> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
>
> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
> registered as /dev/mmcblk1 so that permanent storage is the first
> mmcblk device as I think this is more intuitive however currently
> these get instanced in the order they appear in the imx6qdl.dtsi
> device-tree configuration and are not able to be mapped the way I want
> them in my dts file.
>
> Is there a way, or if not is there a desire for a way, to specify the
> order of /dev/mmcblk devices via device-tree?
As with many other devices, there is no standard way of controlling the
Linux enumeration (and given the ID space is shared with other dynamic
devices it's not something that could generally work).
These should be refererd to by UUID if possible.
If not, we could cosider adding a by-dt-path or something like that.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: specifying order of /dev/mmcblk devices via device-tree?
From: Javier Martinez Canillas @ 2016-10-28 15:37 UTC (permalink / raw)
To: Tim Harvey
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAJ+vNU1g8nQedd06LeaD10YWUQ_UmdRToUMFKaTNT1aNY56b0g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello Tim,
On Fri, Oct 28, 2016 at 12:23 PM, Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org> wrote:
> Greetings,
>
> I have an IMX6 board that has the following:
> sdhc1: mmc0: sdio radio
> sdhc2: mmc1: /dev/mmcblk1: microSD connector
> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
>
> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
> registered as /dev/mmcblk1 so that permanent storage is the first
> mmcblk device as I think this is more intuitive however currently
> these get instanced in the order they appear in the imx6qdl.dtsi
> device-tree configuration and are not able to be mapped the way I want
> them in my dts file.
>
One should not rely on a specific MMC block device numbering, since
this could change. Look at commit 9aaf3437aa72 ("mmc: block: Use the
mmc host device index as the mmcblk device index").
> Is there a way, or if not is there a desire for a way, to specify the
> order of /dev/mmcblk devices via device-tree?
>
There was an attempt to use aliasses for this but got nacked:
https://lkml.org/lkml/2016/4/29/610
As Fabio said, you should either use UUID or labels instead:
https://wiki.archlinux.org/index.php/persistent_block_device_naming
> Regards,
>
> Tim
>
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: specifying order of /dev/mmcblk devices via device-tree?
From: Fabio Estevam @ 2016-10-28 15:33 UTC (permalink / raw)
To: Tim Harvey
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAJ+vNU1g8nQedd06LeaD10YWUQ_UmdRToUMFKaTNT1aNY56b0g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Tim,
On Fri, Oct 28, 2016 at 1:23 PM, Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org> wrote:
> Greetings,
>
> I have an IMX6 board that has the following:
> sdhc1: mmc0: sdio radio
> sdhc2: mmc1: /dev/mmcblk1: microSD connector
> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
>
> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
> registered as /dev/mmcblk1 so that permanent storage is the first
> mmcblk device as I think this is more intuitive however currently
> these get instanced in the order they appear in the imx6qdl.dtsi
> device-tree configuration and are not able to be mapped the way I want
> them in my dts file.
>
> Is there a way, or if not is there a desire for a way, to specify the
> order of /dev/mmcblk devices via device-tree?
You could use UUID to specify the rootfs location on your board.
Please check:
http://git.denx.de/?p=u-boot.git;a=commit;h=ca4f338e2efece5196eb2178e5f7d07be828da6e
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* specifying order of /dev/mmcblk devices via device-tree?
From: Tim Harvey @ 2016-10-28 15:23 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Greetings,
I have an IMX6 board that has the following:
sdhc1: mmc0: sdio radio
sdhc2: mmc1: /dev/mmcblk1: microSD connector
sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
registered as /dev/mmcblk1 so that permanent storage is the first
mmcblk device as I think this is more intuitive however currently
these get instanced in the order they appear in the imx6qdl.dtsi
device-tree configuration and are not able to be mapped the way I want
them in my dts file.
Is there a way, or if not is there a desire for a way, to specify the
order of /dev/mmcblk devices via device-tree?
Regards,
Tim
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: exynos: Use macro for PWM signal polarity in Exynos4 boards
From: Javier Martinez Canillas @ 2016-10-28 13:49 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kukjin Kim, Russell King,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161028134138.GB5646@kozik-lap>
Hello Krzysztof,
On 10/28/2016 10:41 AM, Krzysztof Kozlowski wrote:
> On Thu, Oct 27, 2016 at 02:47:17PM -0300, Javier Martinez Canillas wrote:
>> Using the PWM_POLARITY_INVERTED macro instead of the hardcoded number
>> 0 makes the DTS easier to read.
>
>
> Eeee.... PWM_POLARITY_INVERTED = 1 << 0 = 1.
>
> And you are replacing 0 with 1. Hm? This is not described at all in
> commit message...
>
> Best regards,
> Krzysztof
>
Damn! I don't know how I misread the DTS macro as 0, and didn't find issues
when testing the patches on an Exynos5800 Peach Pi.
I should had run scripts/dtc/dtx_diff to notice that the DTB changed, I'm
so sorry about that...
Please discard the patches.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: exynos: Use macro for PWM signal polarity in Exynos4 boards
From: Krzysztof Kozlowski @ 2016-10-28 13:41 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, devicetree, Kukjin Kim, Russell King,
linux-samsung-soc, Rob Herring, Mark Rutland, Krzysztof Kozlowski,
linux-arm-kernel
In-Reply-To: <1477590438-18095-1-git-send-email-javier@osg.samsung.com>
On Thu, Oct 27, 2016 at 02:47:17PM -0300, Javier Martinez Canillas wrote:
> Using the PWM_POLARITY_INVERTED macro instead of the hardcoded number
> 0 makes the DTS easier to read.
Eeee.... PWM_POLARITY_INVERTED = 1 << 0 = 1.
And you are replacing 0 with 1. Hm? This is not described at all in
commit message...
Best regards,
Krzysztof
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> arch/arm/boot/dts/exynos4412-odroidu3.dts | 3 ++-
> arch/arm/boot/dts/exynos4412-trats2.dts | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> index 99634c54dca9..480a80624b77 100644
> --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> @@ -12,6 +12,7 @@
> */
>
> /dts-v1/;
> +#include <dt-bindings/pwm/pwm.h>
> #include "exynos4412-odroid-common.dtsi"
>
> / {
> @@ -35,7 +36,7 @@
>
> fan0: pwm-fan {
> compatible = "pwm-fan";
> - pwms = <&pwm 0 10000 0>;
> + pwms = <&pwm 0 10000 PWM_POLARITY_INVERTED>;
> cooling-min-state = <0>;
> cooling-max-state = <3>;
> #cooling-cells = <2>;
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 41ecd6d465a7..63ad30507d4f 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -18,6 +18,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/clock/maxim,max77686.h>
> +#include <dt-bindings/pwm/pwm.h>
>
> / {
> model = "Samsung Trats 2 based on Exynos4412";
> @@ -164,7 +165,7 @@
> max77693_haptic {
> compatible = "maxim,max77693-haptic";
> haptic-supply = <&ldo26_reg>;
> - pwms = <&pwm 0 38022 0>;
> + pwms = <&pwm 0 38022 PWM_POLARITY_INVERTED>;
> };
>
> charger {
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: exynos: Document eMMC/SD/SDIO devices in Exynos5250 Snow board
From: Javier Martinez Canillas @ 2016-10-28 13:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-kernel, devicetree, Kukjin Kim, Russell King,
linux-samsung-soc, Rob Herring, Mark Rutland, linux-arm-kernel
In-Reply-To: <20161028133424.GA5646@kozik-lap>
Hello Krzysztof,
On 10/28/2016 10:34 AM, Krzysztof Kozlowski wrote:
> On Thu, Oct 27, 2016 at 02:11:41PM -0300, Javier Martinez Canillas wrote:
>> There's a cognitive load to figure out which mmc device node corresponds
>> to the eMMC flash, uSD card and WiFI SDIO module on the Snow boards.
>>
>> So it's better to have comments in the DTS to make this more clear.
>>
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> ---
>>
>> arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 ++++
>> 1 file changed, 4 insertions(+)
>
> Thanks, applied after squashing three into one. These are only comments,
> so no impact on the code, and meaning/goal of them is exactly same.
>
Ok, sounds good to me. Thanks!
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: exynos: Document eMMC/SD/SDIO devices in Exynos5250 Snow board
From: Krzysztof Kozlowski @ 2016-10-28 13:34 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, devicetree, Kukjin Kim, Russell King,
linux-samsung-soc, Rob Herring, Mark Rutland, Krzysztof Kozlowski,
linux-arm-kernel
In-Reply-To: <1477588303-13681-1-git-send-email-javier@osg.samsung.com>
On Thu, Oct 27, 2016 at 02:11:41PM -0300, Javier Martinez Canillas wrote:
> There's a cognitive load to figure out which mmc device node corresponds
> to the eMMC flash, uSD card and WiFI SDIO module on the Snow boards.
>
> So it's better to have comments in the DTS to make this more clear.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
Thanks, applied after squashing three into one. These are only comments,
so no impact on the code, and meaning/goal of them is exactly same.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/3] reset: Add the TI SCI reset driver
From: Nishanth Menon @ 2016-10-28 13:20 UTC (permalink / raw)
To: Philipp Zabel
Cc: Andrew F. Davis, Mark Rutland, dt list, lkml, Tero Kristo,
Rob Herring, Santosh Shilimkar,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1477647364.3010.28.camel@pengutronix.de>
On Fri, Oct 28, 2016 at 4:36 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Hi Andrew,
>
> is there (going to be) as stable branch I can base these on, or should I
> just wait until the prerequisite patches appear in arm-soc/for-next?
>
TISCI is still to be merged.
http://marc.info/?l=linux-arm-kernel&m=147756439730680&w=2 pull
request for 4.10 was send out recently.
---
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH resent v3 2/3] dts: omap5: board-common: enable twl6040 headset jack detection
From: Tony Lindgren @ 2016-10-28 13:11 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: H. Nikolaus Schaller, Benoît Cousson, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
Russell King, devicetree, letux-kernel, linux-kernel, ldewangan,
kernel, marek, linux-omap
In-Reply-To: <06084abe-015a-ed84-2ce3-779be5744773@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [161026 01:03]:
> On 10/25/16 20:38, H. Nikolaus Schaller wrote:
> > Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>
> I'm not sure if this is valid for igep0500 as I have not seen the schematics.
> It might be safer to enable the jack detection only for omap5-uevm?
FYI it's pretty much the same design and audio worked fine on igepv5
the last time I tested it. I guess a good reason to drill a new hole
to my pi-top case for the audio jack :)
Tony
^ permalink raw reply
* Re: [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Tony Lindgren @ 2016-10-28 12:51 UTC (permalink / raw)
To: Tero Kristo
Cc: Stephen Boyd, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
mturquette-rdvid1DuHRBWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring
In-Reply-To: <cd32a554-ba0a-33cd-c15c-121524ce679b-l0cyMroinI0@public.gmane.org>
* Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org> [161028 00:43]:
> On 28/10/16 03:50, Stephen Boyd wrote:
> > I suppose a PRCM is
> > like an MFD that has clocks and resets under it? On other
> > platforms we've combined that all into one node and just had
> > #clock-cells and #reset-cells in that node. Is there any reason
> > we can't do that here?
>
> For OMAPs, there are typically multiple instances of the PRCM around; OMAP4
> for example has:
>
> cm1 @ 0x4a004000 (clocks + clockdomains)
> cm2 @ 0x4a008000 (clocks + clockdomains)
> prm @ 0x4a306000 (few clocks + resets + power state handling)
> scrm @ 0x4a30a000 (few external clocks + plenty of misc stuff)
>
> These instances are also under different power/voltage domains which means
> their PM behavior is different.
>
> The idea behind having a clockdomain as a provider was mostly to have the
> topology visible : prcm-instance -> clockdomain -> clocks
Yeah that's needed to get the interconnect hierarchy right for
genpd :)
> ... but basically I think it would be possible to drop the clockdomain
> representation and just mark the prcm-instance as a clock provider. Tony,
> any thoughts on that?
No let's not drop the clockdomains as those will be needed when we
move things into proper hierarchy within the interconnect instances.
This will then help with getting things right with genpd.
In the long run we just want to specify clockdomain and the offset of
the clock instance within the clockdomain in the dts files.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 8/8] mfd: tps65217: Fix mismatched interrupt number
From: Milo Kim @ 2016-10-28 12:37 UTC (permalink / raw)
To: bcousson, Tony Lindgren
Cc: linux-omap, devicetree, linux-arm-kernel, linux-kernel, Lee Jones,
Robert Nelson, Milo Kim
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
Enum value of 'tps65217_irq_type' is not matched with DT parsed hwirq
number[*].
The MFD driver gets the IRQ data by referencing hwirq, but the value is
different. So, irq_to_tps65217_irq() returns mismatched IRQ data.
Eventually, the power button driver enables not PB but USB interrupt
when it is probed.
According to the TPS65217 register map[**], USB interrupt is the LSB.
This patch defines synchronized IRQ value.
[*] include/dt-bindings/mfd/tps65217.h
[**] http://www.ti.com/lit/ds/symlink/tps65217.pdf
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
include/linux/mfd/tps65217.h | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/include/linux/mfd/tps65217.h b/include/linux/mfd/tps65217.h
index 4ccda89..3cbec4b 100644
--- a/include/linux/mfd/tps65217.h
+++ b/include/linux/mfd/tps65217.h
@@ -234,12 +234,11 @@ struct tps65217_bl_pdata {
int dft_brightness;
};
-enum tps65217_irq_type {
- TPS65217_IRQ_PB,
- TPS65217_IRQ_AC,
- TPS65217_IRQ_USB,
- TPS65217_NUM_IRQ
-};
+/* Interrupt numbers */
+#define TPS65217_IRQ_USB 0
+#define TPS65217_IRQ_AC 1
+#define TPS65217_IRQ_PB 2
+#define TPS65217_NUM_IRQ 3
/**
* struct tps65217_board - packages regulator init data
--
2.9.3
^ permalink raw reply related
* [PATCH v2 7/8] ARM: dts: am335x: Add the power button interrupt
From: Milo Kim @ 2016-10-28 12:37 UTC (permalink / raw)
To: bcousson, Tony Lindgren
Cc: linux-omap, devicetree, linux-arm-kernel, linux-kernel, Lee Jones,
Robert Nelson, Milo Kim
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
This enables the power button driver gets corresponding IRQ number by
using platform_get_irq().
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index cec9d91..0c0a90c 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -324,6 +324,11 @@
status = "okay";
};
+ pwrbutton {
+ interrupts = <TPS65217_IRQ_PB>;
+ status = "okay";
+ };
+
regulators {
dcdc1_reg: regulator@0 {
regulator-name = "vdds_dpr";
--
2.9.3
^ permalink raw reply related
* [PATCH v2 6/8] ARM: dts: am335x: Add the charger interrupt
From: Milo Kim @ 2016-10-28 12:37 UTC (permalink / raw)
To: bcousson, Tony Lindgren
Cc: linux-omap, devicetree, linux-arm-kernel, linux-kernel, Lee Jones,
Robert Nelson, Milo Kim
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
This enables the charger driver gets corresponding IRQ number by using
platform_get_irq_byname() helper.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 25303d9..cec9d91 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -6,6 +6,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/mfd/tps65217.h>
+
/ {
cpus {
cpu@0 {
@@ -316,6 +318,12 @@
ti,pmic-shutdown-controller;
+ charger {
+ interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
+ interrupts-names = "AC", "USB";
+ status = "okay";
+ };
+
regulators {
dcdc1_reg: regulator@0 {
regulator-name = "vdds_dpr";
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/8] dt-bindings: mfd: Provide human readable defines for TPS65217 interrupts
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: bcousson, Tony Lindgren
Cc: linux-omap, devicetree, linux-arm-kernel, linux-kernel, Lee Jones,
Robert Nelson, Milo Kim
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
TPS65217 supports three interrupt sources. This patch enables assigning
each IRQ number in the charger and power button node. Then corresponding
IRQ will be requested by each driver.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
include/dt-bindings/mfd/tps65217.h | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 include/dt-bindings/mfd/tps65217.h
diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
new file mode 100644
index 0000000..cafb9e6
--- /dev/null
+++ b/include/dt-bindings/mfd/tps65217.h
@@ -0,0 +1,26 @@
+/*
+ * This header provides macros for TI TPS65217 DT bindings.
+ *
+ * Copyright (C) 2016 Texas Instruments
+ *
+ * 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.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __DT_BINDINGS_TPS65217_H__
+#define __DT_BINDINGS_TPS65217_H__
+
+#define TPS65217_IRQ_USB 0
+#define TPS65217_IRQ_AC 1
+#define TPS65217_IRQ_PB 2
+
+#endif
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/8] ARM: dts: am335x: Support the PMIC interrupt
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: bcousson, Tony Lindgren
Cc: linux-omap, devicetree, linux-arm-kernel, linux-kernel, Lee Jones,
Robert Nelson, Milo Kim
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
AM335x bone based boards have the PMIC interrupt named NMI which is
connected to TPS65217 device. AM335x main interrupt controller provides it
and the number is 7.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 007b5e5..25303d9 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -310,6 +310,10 @@
* by the hardware problems. (Tip: double-check by performing a current
* measurement after shutdown: it should be less than 1 mA.)
*/
+
+ interrupts = <7>; /* NMI */
+ interrupt-parent = <&intc>;
+
ti,pmic-shutdown-controller;
regulators {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/8] ARM: dts: tps65217: Add the power button device
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: bcousson, Tony Lindgren
Cc: linux-omap, devicetree, linux-arm-kernel, linux-kernel, Lee Jones,
Robert Nelson, Milo Kim
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
Support the power button driver and disable it by default.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/tps65217.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index 8f77d0d..02de56b 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -21,6 +21,11 @@
status = "disabled";
};
+ pwrbutton {
+ compatible = "ti,tps65217-pwrbutton";
+ status = "disabled";
+ };
+
regulators {
#address-cells = <1>;
#size-cells = <0>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/8] ARM: dts: tps65217: Add the charger device
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: bcousson, Tony Lindgren
Cc: devicetree, Lee Jones, linux-kernel, Milo Kim, linux-omap,
Robert Nelson, linux-arm-kernel
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
Support the charger driver and disable it by default.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/tps65217.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index 27935f8..8f77d0d 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -16,6 +16,11 @@
interrupt-controller;
#interrupt-cells = <1>;
+ charger {
+ compatible = "ti,tps65217-charger";
+ status = "disabled";
+ };
+
regulators {
#address-cells = <1>;
#size-cells = <0>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/8] ARM: dts: tps65217: Specify the interrupt controller
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: bcousson, Tony Lindgren
Cc: linux-omap, devicetree, linux-arm-kernel, linux-kernel, Lee Jones,
Robert Nelson, Milo Kim
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
TPS65217 MFD driver supports the IRQ domain to handle the charger input
interrupts and push button status event. The interrupt controller enables
corresponding IRQ handling in the charger[*] and power button driver[**].
[*] drivers/power/supply/tps65217_charger.c
[**] drivers/input/misc/tps65218-pwrbutton.c
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/tps65217.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index a632724..27935f8 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -13,6 +13,8 @@
&tps {
compatible = "ti,tps65217";
+ interrupt-controller;
+ #interrupt-cells = <1>;
regulators {
#address-cells = <1>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/8] Support TPS65217 PMIC interrupt in DT
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: bcousson-rdvid1DuHRBWk0Htik3J/w, Tony Lindgren
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Lee Jones, Robert Nelson,
Milo Kim
TPS65217 interrupt events include push button pressed/released, USB and AC
voltage status change. AM335x bone based boards (like BB, BBB, BBG) have
common PMIC interrupt pin (named NMI) of AM335x core.
This patchset support interrupts in device tree file.
v2:
Add missing a dt-binding header
Use #defines instead of enum type for interrupt numbers
Milo Kim (8):
ARM: dts: tps65217: Specify the interrupt controller
ARM: dts: tps65217: Add the charger device
ARM: dts: tps65217: Add the power button device
ARM: dts: am335x: Support the PMIC interrupt
dt-bindings: mfd: Provide human readable defines for TPS65217
interrupts
ARM: dts: am335x: Add the charger interrupt
ARM: dts: am335x: Add the power button interrupt
mfd: tps65217: Fix mismatched interrupt number
arch/arm/boot/dts/am335x-bone-common.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/tps65217.dtsi | 12 ++++++++++++
include/dt-bindings/mfd/tps65217.h | 26 ++++++++++++++++++++++++++
include/linux/mfd/tps65217.h | 11 +++++------
4 files changed, 60 insertions(+), 6 deletions(-)
create mode 100644 include/dt-bindings/mfd/tps65217.h
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox