* [PATCH linux v1 0/4] Seven segment display support
From: Thomas Petazzoni @ 2016-12-14 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481702104-8617-1-git-send-email-jaghu@google.com>
Hello,
On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
Natarajan wrote:
> Documentation for the binding which provides an interface for adding clock,
> data and clear signal GPIO lines to control seven segment display.
>
> The platform device driver provides an API for displaying on two 7-segment
> displays, and implements the required bit-banging. The hardware assumed is
> 74HC164 wired to two 7-segment displays.
>
> The character device driver implements the user-space API for letting a user
> write to two 7-segment displays including any conversion methods necessary
> to map the user input to two 7-segment displays.
>
> Adding clock, data and clear signal GPIO lines in the devicetree to control
> seven segment display on zaius platform.
>
> The platform driver matches on the device tree node; the platform driver also
> initializes the character device.
>
> Tested that the seven segment display works properly by writing to the
> character device file on a EVB AST2500 board which also has 74HC164 wired
> to two 7-segment displays.
FWIW, I proposed a driver for seven segment displays back in 2013:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
And the feedback from Greg KH was: we don't need a driver for that, do
it from userspace. See:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
So: good luck :-)
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: dts: dra72-evm-tps65917: Add voltage supplies to usb_phy, mmc, dss
From: Roger Quadros @ 2016-12-14 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <972859e0-30ff-8170-d5d3-af9b8591276b@ti.com>
On 14/12/16 14:35, Lokesh Vutla wrote:
>
>
> On Wednesday 14 December 2016 04:30 PM, Roger Quadros wrote:
>> Lokesh,
>>
>> On 14/12/16 10:57, Lokesh Vutla wrote:
>>> Commit 5d080aa30681 ("ARM: dts: dra72: Add separate dtsi for tps65917")
>>> added a separate dtsi for dra72-evm-tps65917 moving all the voltage supplies
>>> to this file. But it missed adding voltage supplies to usb_phy, mmc,
>>> dss and deleted from dra72-evm-common.dtsi. Adding the voltage supply
>>> phandles to these nodes in dra72-evm-tps65917.dtsi
>>>
>>> Fixes: 5d080aa30681 ("ARM: dts: dra72: Add separate dtsi for tps65917")
>>> Reported-by: Carlos Hernandez <ceh@ti.com>
>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>>> ---
>>> Logs:
>>> - DRA72-evm revC: http://pastebin.ubuntu.com/23627665/
>>> - DRA72-evm revB: http://pastebin.ubuntu.com/23627658/
>>> arch/arm/boot/dts/dra72-evm-tps65917.dtsi | 16 ++++++++++++++++
>>> 1 file changed, 16 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/dra72-evm-tps65917.dtsi b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
>>> index ee6dac44edf1..e6df676886c0 100644
>>> --- a/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
>>> +++ b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
>>> @@ -132,3 +132,19 @@
>>> ti,palmas-long-press-seconds = <6>;
>>> };
>>> };
>>> +
>>> +&usb2_phy1 {
>>> + phy-supply = <&ldo4_reg>;
>>> +};
>>> +
>>> +&usb2_phy2 {
>>> + phy-supply = <&ldo4_reg>;
>>> +};
>>> +
>>> +&dss {
>>> + vdda_video-supply = <&ldo5_reg>;
>>> +};
>>> +
>>> +&mmc1 {
>>> + vmmc_aux-supply = <&ldo1_reg>;
>>> +};
>>>
>>
>> Are you sure that all future users of dra72-evm-tps65917.dtsi will use this same configuration?
>> If not I'd rather put this in the board dts files.
>
> hmm..This debate already happened when creating dra72-evm-tps65917 file
> and concluded that all the common regulator stuff on dra72 evm revA,B,C
> should go in this file. Any new board which is not similar to dra72-evm
> will not be using this file.
OK, then it is fine. Thanks for clarifying.
cheers,
-roger
^ permalink raw reply
* [PATCH 2/2] ARM: soft-reboot into same mode that we entered the kernel
From: Russell King - ARM Linux @ 2016-12-14 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214124056.GI17982@leverpostej>
On Wed, Dec 14, 2016 at 12:40:56PM +0000, Mark Rutland wrote:
> On Wed, Dec 14, 2016 at 12:29:45PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Dec 14, 2016 at 12:17:47PM +0000, Mark Rutland wrote:
> > > On Wed, Dec 14, 2016 at 12:05:41PM +0000, Russell King - ARM Linux wrote:
> > > > The issue here is that a panic can happen at any time from any context
> > > > with any hyp stub in place, so there _needs_ to be a uniform way to do
> > > > this. It's very bad that we've got this far without this point having
> > > > been considered - all we can do right now is to try and fix the issues
> > > > as they come up.
> > > >
> > > > Right now, let's fix this so we get some kind of improvement, and later
> > > > try to sort out some kind of uniform interface for this task.
> > >
> > > Sure, that's a bigger task, and this is definitely a step in the right
> > > direction.
> > >
> > > We need to avoid the kdump regression somehow though; can we somehow
> > > detect if KVM is active and avoid issuing the HVC_SOFT_RESTART?
> >
> > That's a question for KVM people.
> >
> > However, there's a bigger question, which is: what do we want to happen
> > in the case of kdump - do we want to be entering the kdump kernel in
> > HYP or SVC mode? As the kdump kernel exists to be able to save the
> > state of a crashing system, the kdump kernel should do that and then
> > restart the system in a clean way (iow, not via yet another kexec.)
> >
> > So maybe the right answer is that kdump should always invoke the kernel
> > in SVC mode.
>
> Personally, my view is the opposite -- we should always exit the way we
> came, and kdump can go from there. Otherwise we're leaving context
> active in hyp mode that might hinder kdump (or would otherwise be useful
> for kdump to be able to access).
>
> For example, we might want to do something like kernel guard, where even
> the host kernel would have a stage-2 translation active in hyp that we'd
> need to tear down. That, or the hyp page table might have been
> corrupted, and tearing down ASAP might save us from asynchrnous issues
> from page table walks. It's all a trade-off, either way -- the hyp code
> could also be corrupt.
However, the issue there is that if there is a hyp page table present,
it means that we're no longer saving out a true image of the running
system - the core dump expects to be an image as seen from previously
running kernel, which would be in SVC mode.
If we save out the view of memory from HYP mode, we're no longer saving
out the same thing - and the physical addresses which are stored within
kdump for things like the CPU states (which are physical addresses as
seen in SVC mode) are no longer valid.
So, to make kdump work in this situation probably needs a significant
rework of kdump's idea of what a physical address is.
In the mean time, I think the approach I've put forward is the only
sensible one until we can be sure that a HYP mode core-dump really does
make sense.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]
From: Pavel Machek @ 2016-12-14 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201612141321.30181@pali>
Hi!
> > [ 220.248596] tty ttyO1: Radio packet sent
> > [ 220.249328] Bluetooth: hci0: Frame reassembly failed (-84)
> > [ 220.272949] tty ttyO1: wakeup received: 1 -> 0
> > [ 221.283477] tty ttyO1: radio packet timeout!
> > [ 221.283630] enqueue: hu c304cc80 skb cd4a9b40
> > [ 223.363372] Bluetooth: hci0 command 0xfc18 tx timeout
> > pavel at n900:~$
>
> In log are still some failures, but ... is bluetooth working now?
It is... for Sebastian. I'm playing with camera now.
> I see that you applied this patch:
> https://git.kernel.org/cgit/linux/kernel/git/pavel/linux-n900.git/commit/?id=051aa3fbf03ac770d8344690f5a936a7f04c6884
>
> Looks like that pinmux is in DTS file incorrect. Can somebody verify it?
> Maybe Tony?
Yes, it is. Sebastian was pretty certain about that.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/615b77da/attachment-0001.sig>
^ permalink raw reply
* [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Andrei Pistirica @ 2016-12-14 12:56 UTC (permalink / raw)
To: linux-arm-kernel
Cadence GEM provides a 102 bit time counter with 48 bits for seconds,
30 bits for nsecs and 24 bits for sub-nsecs to control 1588 timestamping.
This patch does the following:
- Registers to ptp clock framework
- Timer initialization is done by writing time of day to the timer counter.
- ns increment register is programmed as NSEC_PER_SEC/tsu-clock-rate.
For a 16 bit subns precision, the subns increment equals
remainder of (NS_PER_SEC/TSU_CLK) * (2^16).
- Timestamps are obtained from the TX/RX PTP event/PEER registers.
The timestamp obtained thus is updated in skb for upper layers to access.
- The drivers register functions with ptp to perform time and frequency
adjustment.
- Time adjustment is done by writing to the 1558_ADJUST register.
The controller will read the delta in this register and update the timer
counter register. Alternatively, for large time offset adjustments,
the driver reads the secs and nsecs counter values, adds/subtracts the
delta and updates the timer counter.
- Frequency is adjusted by adjusting addend (8bit nanosecond increment) and
addendsub (16bit increment nanosecond fractions).
The 102bit counter is incremented at nominal frequency with addend and
addendsub values. Each period addend and addendsub values are adjusted
based on ppm drift.
Signed-off-by: Andrei Pistirica <andrei.pistirica@microchip.com>
Signed-off-by: Harini Katakam <harinik@xilinx.com>
---
Patch history:
Version 1:
This patch is based on original Harini's patch, implemented in a
separate file to ease the review/maintanance and integration with
other platforms (e.g. Zynq Ultrascale+ MPSoC).
Feature was tested on SAMA5D2 platform using ptp4l v1.6 from linuxptp
project and also with ptpd2 version 2.3.1. PTP was tested over
IPv4,IPv6 and 802.3 protocols.
In case that macb is compiled as a module, it has been renamed to
cadence-macb.ko to avoid naming confusion in Makefile.
Version 2 modifications:
- bitfields for TSU are named according to SAMA5D2 data sheet
- identify GEM-PTP support based on platform capability
- add spinlock for TSU access
- change macb_ptp_adjfreq and use fewer 64bit divisions
Version 3 modifications:
- new adjfine api with one 64 division for frequency adjustment
(based on Richard's input)
- add maximum adjustment frequency (ppb) based on nominal frequency
- per platform PTP configuration
- cosmetic changes
Note 1: Kbuild uses "select" instead of "imply", and the macb maintainer agreed
to make the change when it will be available in net-next.
Version 4 modifications:
- update adjfine for a better approximation
- add maximum adjustment frequency callback to PTP platform configuraion
Note 1: This driver does not support GEM-GXL!
Note 2: Patch on net-next, on December 14th.
drivers/net/ethernet/cadence/Kconfig | 10 +-
drivers/net/ethernet/cadence/Makefile | 8 +-
drivers/net/ethernet/cadence/macb.h | 118 ++++++++++
drivers/net/ethernet/cadence/macb_ptp.c | 366 ++++++++++++++++++++++++++++++++
4 files changed, 500 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/ethernet/cadence/macb_ptp.c
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index f0bcb15..ebbc65f 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -29,6 +29,14 @@ config MACB
support for the MACB/GEM chip.
To compile this driver as a module, choose M here: the module
- will be called macb.
+ will be called cadence-macb.
+
+config MACB_USE_HWSTAMP
+ bool "Use IEEE 1588 hwstamp"
+ depends on MACB
+ default y
+ select PTP_1588_CLOCK
+ ---help---
+ Enable IEEE 1588 Precision Time Protocol (PTP) support for MACB.
endif # NET_CADENCE
diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
index 91f79b1..4402d42 100644
--- a/drivers/net/ethernet/cadence/Makefile
+++ b/drivers/net/ethernet/cadence/Makefile
@@ -2,4 +2,10 @@
# Makefile for the Atmel network device drivers.
#
-obj-$(CONFIG_MACB) += macb.o
+cadence-macb-y := macb.o
+
+ifeq ($(CONFIG_MACB_USE_HWSTAMP),y)
+cadence-macb-y += macb_ptp.o
+endif
+
+obj-$(CONFIG_MACB) += cadence-macb.o
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index d67adad..e65e985 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -10,6 +10,9 @@
#ifndef _MACB_H
#define _MACB_H
+#include <linux/ptp_clock.h>
+#include <linux/ptp_clock_kernel.h>
+
#define MACB_GREGS_NBR 16
#define MACB_GREGS_VERSION 2
#define MACB_MAX_QUEUES 8
@@ -131,6 +134,20 @@
#define GEM_RXIPCCNT 0x01a8 /* IP header Checksum Error Counter */
#define GEM_RXTCPCCNT 0x01ac /* TCP Checksum Error Counter */
#define GEM_RXUDPCCNT 0x01b0 /* UDP Checksum Error Counter */
+#define GEM_TISUBN 0x01bc /* 1588 Timer Increment Sub-ns */
+#define GEM_TSH 0x01c0 /* 1588 Timer Seconds High */
+#define GEM_TSL 0x01d0 /* 1588 Timer Seconds Low */
+#define GEM_TN 0x01d4 /* 1588 Timer Nanoseconds */
+#define GEM_TA 0x01d8 /* 1588 Timer Adjust */
+#define GEM_TI 0x01dc /* 1588 Timer Increment */
+#define GEM_EFTSL 0x01e0 /* PTP Event Frame Tx Seconds Low */
+#define GEM_EFTN 0x01e4 /* PTP Event Frame Tx Nanoseconds */
+#define GEM_EFRSL 0x01e8 /* PTP Event Frame Rx Seconds Low */
+#define GEM_EFRN 0x01ec /* PTP Event Frame Rx Nanoseconds */
+#define GEM_PEFTSL 0x01f0 /* PTP Peer Event Frame Tx Secs Low */
+#define GEM_PEFTN 0x01f4 /* PTP Peer Event Frame Tx Ns */
+#define GEM_PEFRSL 0x01f8 /* PTP Peer Event Frame Rx Sec Low */
+#define GEM_PEFRN 0x01fc /* PTP Peer Event Frame Rx Ns */
#define GEM_DCFG1 0x0280 /* Design Config 1 */
#define GEM_DCFG2 0x0284 /* Design Config 2 */
#define GEM_DCFG3 0x0288 /* Design Config 3 */
@@ -174,6 +191,7 @@
#define MACB_NCR_TPF_SIZE 1
#define MACB_TZQ_OFFSET 12 /* Transmit zero quantum pause frame */
#define MACB_TZQ_SIZE 1
+#define MACB_SRTSM_OFFSET 15
/* Bitfields in NCFGR */
#define MACB_SPD_OFFSET 0 /* Speed */
@@ -319,6 +337,32 @@
#define MACB_PTZ_SIZE 1
#define MACB_WOL_OFFSET 14 /* Enable wake-on-lan interrupt */
#define MACB_WOL_SIZE 1
+#define MACB_DRQFR_OFFSET 18 /* PTP Delay Request Frame Received */
+#define MACB_DRQFR_SIZE 1
+#define MACB_SFR_OFFSET 19 /* PTP Sync Frame Received */
+#define MACB_SFR_SIZE 1
+#define MACB_DRQFT_OFFSET 20 /* PTP Delay Request Frame Transmitted */
+#define MACB_DRQFT_SIZE 1
+#define MACB_SFT_OFFSET 21 /* PTP Sync Frame Transmitted */
+#define MACB_SFT_SIZE 1
+#define MACB_PDRQFR_OFFSET 22 /* PDelay Request Frame Received */
+#define MACB_PDRQFR_SIZE 1
+#define MACB_PDRSFR_OFFSET 23 /* PDelay Response Frame Received */
+#define MACB_PDRSFR_SIZE 1
+#define MACB_PDRQFT_OFFSET 24 /* PDelay Request Frame Transmitted */
+#define MACB_PDRQFT_SIZE 1
+#define MACB_PDRSFT_OFFSET 25 /* PDelay Response Frame Transmitted */
+#define MACB_PDRSFT_SIZE 1
+#define MACB_SRI_OFFSET 26 /* TSU Seconds Register Increment */
+#define MACB_SRI_SIZE 1
+
+/* Timer increment fields */
+#define MACB_TI_CNS_OFFSET 0
+#define MACB_TI_CNS_SIZE 8
+#define MACB_TI_ACNS_OFFSET 8
+#define MACB_TI_ACNS_SIZE 8
+#define MACB_TI_NIT_OFFSET 16
+#define MACB_TI_NIT_SIZE 8
/* Bitfields in MAN */
#define MACB_DATA_OFFSET 0 /* data */
@@ -386,6 +430,17 @@
#define GEM_PBUF_LSO_OFFSET 27
#define GEM_PBUF_LSO_SIZE 1
+/* Bitfields in TISUBN */
+#define GEM_SUBNSINCR_OFFSET 0
+#define GEM_SUBNSINCR_SIZE 16
+
+/* Bitfields in TI */
+#define GEM_NSINCR_OFFSET 0
+#define GEM_NSINCR_SIZE 8
+
+/* Bitfields in ADJ */
+#define GEM_ADDSUB_OFFSET 31
+#define GEM_ADDSUB_SIZE 1
/* Constants for CLK */
#define MACB_CLK_DIV8 0
#define MACB_CLK_DIV16 1
@@ -417,6 +472,7 @@
#define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x20000000
#define MACB_CAPS_SG_DISABLED 0x40000000
#define MACB_CAPS_MACB_IS_GEM 0x80000000
+#define MACB_CAPS_GEM_HAS_PTP 0x00000020
/* LSO settings */
#define MACB_LSO_UFO_ENABLE 0x01
@@ -782,6 +838,20 @@ struct macb_or_gem_ops {
int (*mog_rx)(struct macb *bp, int budget);
};
+/* MACB-PTP interface: adapt to platform needs and GEM (e.g. GXL). */
+struct macb_ptp_info {
+ void (*ptp_init)(struct net_device *ndev);
+ void (*ptp_remove)(struct net_device *ndev);
+ s32 (*get_ptp_max_adj)(void);
+ unsigned int (*get_tsu_rate)(struct macb *bp);
+ int (*get_ts_info)(struct net_device *dev,
+ struct ethtool_ts_info *info);
+ int (*get_hwtst)(struct net_device *netdev,
+ struct ifreq *ifr);
+ int (*set_hwtst)(struct net_device *netdev,
+ struct ifreq *ifr, int cmd);
+};
+
struct macb_config {
u32 caps;
unsigned int dma_burst_length;
@@ -874,11 +944,59 @@ struct macb {
unsigned int jumbo_max_len;
u32 wol;
+
+ struct macb_ptp_info *ptp_info;
+#ifdef CONFIG_MACB_USE_HWSTAMP
+ bool hwts_tx_en;
+ bool hwts_rx_en;
+ spinlock_t tsu_clk_lock; /* gem tsu clock locking */
+ unsigned int tsu_rate;
+
+ struct ptp_clock *ptp_clock;
+ struct ptp_clock_info ptp_caps;
+ u32 ns_incr;
+ u32 subns_incr;
+#endif
};
+#ifdef CONFIG_MACB_USE_HWSTAMP
+void gem_ptp_init(struct net_device *ndev);
+void gem_ptp_remove(struct net_device *ndev);
+void gem_ptp_txstamp(struct macb *bp, struct sk_buff *skb);
+void gem_ptp_rxstamp(struct macb *bp, struct sk_buff *skb);
+
+static inline void gem_ptp_do_txstamp(struct macb *bp, struct sk_buff *skb)
+{
+ if (!bp->hwts_tx_en)
+ return;
+
+ return gem_ptp_txstamp(bp, skb);
+}
+
+static inline void gem_ptp_do_rxstamp(struct macb *bp, struct sk_buff *skb)
+{
+ if (!bp->hwts_rx_en)
+ return;
+
+ return gem_ptp_rxstamp(bp, skb);
+}
+
+#else
+static inline void gem_ptp_init(struct net_device *ndev) { }
+static inline void gem_ptp_remove(struct net_device *ndev) { }
+
+static inline void gem_ptp_do_txstamp(struct macb *bp, struct sk_buff *skb) { }
+static inline void gem_ptp_do_rxstamp(struct macb *bp, struct sk_buff *skb) { }
+#endif
+
static inline bool macb_is_gem(struct macb *bp)
{
return !!(bp->caps & MACB_CAPS_MACB_IS_GEM);
}
+static inline bool gem_has_ptp(struct macb *bp)
+{
+ return !!(bp->caps & MACB_CAPS_GEM_HAS_PTP);
+}
+
#endif /* _MACB_H */
diff --git a/drivers/net/ethernet/cadence/macb_ptp.c b/drivers/net/ethernet/cadence/macb_ptp.c
new file mode 100644
index 0000000..6121b2a
--- /dev/null
+++ b/drivers/net/ethernet/cadence/macb_ptp.c
@@ -0,0 +1,366 @@
+/*
+ * 1588 PTP support for GEM device.
+ *
+ * Copyright (C) 2016 Microchip Technology
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/etherdevice.h>
+#include <linux/platform_device.h>
+#include <linux/time64.h>
+#include <linux/ptp_classify.h>
+#include <linux/if_ether.h>
+#include <linux/if_vlan.h>
+#include <linux/net_tstamp.h>
+
+#include "macb.h"
+
+#define GEM_PTP_TIMER_NAME "gem-ptp-timer"
+
+static inline void gem_tsu_get_time(struct macb *bp,
+ struct timespec64 *ts)
+{
+ u64 sec, sech, secl;
+
+ spin_lock(&bp->tsu_clk_lock);
+
+ /* GEM's internal time */
+ sech = gem_readl(bp, TSH);
+ secl = gem_readl(bp, TSL);
+ ts->tv_nsec = gem_readl(bp, TN);
+ ts->tv_sec = (sech << 32) | secl;
+
+ /* minimize error */
+ sech = gem_readl(bp, TSH);
+ secl = gem_readl(bp, TSL);
+ sec = (sech << 32) | secl;
+ if (ts->tv_sec != sec) {
+ ts->tv_sec = sec;
+ ts->tv_nsec = gem_readl(bp, TN);
+ }
+
+ spin_unlock(&bp->tsu_clk_lock);
+}
+
+static inline void gem_tsu_set_time(struct macb *bp,
+ const struct timespec64 *ts)
+{
+ u32 ns, sech, secl;
+ s64 word_mask = 0xffffffff;
+
+ sech = (u32)ts->tv_sec;
+ secl = (u32)ts->tv_sec;
+ ns = ts->tv_nsec;
+ if (ts->tv_sec > word_mask)
+ sech = (ts->tv_sec >> 32);
+
+ spin_lock(&bp->tsu_clk_lock);
+
+ /* TSH doesn't latch the time and no atomicity! */
+ gem_writel(bp, TN, 0); /* clear to avoid overflow */
+ gem_writel(bp, TSH, sech);
+ gem_writel(bp, TSL, secl);
+ gem_writel(bp, TN, ns);
+
+ spin_unlock(&bp->tsu_clk_lock);
+}
+
+static int gem_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
+{
+ struct macb *bp = container_of(ptp, struct macb, ptp_caps);
+ u32 word, diff;
+ u64 adj, rate;
+ int neg_adj = 0;
+
+ if (scaled_ppm < 0) {
+ neg_adj = 1;
+ scaled_ppm = -scaled_ppm;
+ }
+ rate = scaled_ppm;
+
+ /* word: unused(8bit) | ns(8bit) | fractions(16bit) */
+ word = (bp->ns_incr << 16) + bp->subns_incr;
+
+ adj = word;
+ adj *= rate;
+ adj += 500000UL << 16;
+ adj >>= 16; /* remove fractions */
+ diff = div_u64(adj, 1000000UL);
+ word = neg_adj ? word - diff : word + diff;
+
+ spin_lock(&bp->tsu_clk_lock);
+
+ gem_writel(bp, TISUBN, GEM_BF(SUBNSINCR, (word & 0xffff)));
+ gem_writel(bp, TI, GEM_BF(NSINCR, (word >> 16)));
+
+ spin_unlock(&bp->tsu_clk_lock);
+ return 0;
+}
+
+static int gem_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
+{
+ struct macb *bp = container_of(ptp, struct macb, ptp_caps);
+ struct timespec64 now, then = ns_to_timespec64(delta);
+ u32 adj, sign = 0;
+
+ if (delta < 0) {
+ delta = -delta;
+ sign = 1;
+ }
+
+ if (delta > 0x3FFFFFFF) {
+ gem_tsu_get_time(bp, &now);
+
+ if (sign)
+ now = timespec64_sub(now, then);
+ else
+ now = timespec64_add(now, then);
+
+ gem_tsu_set_time(bp, (const struct timespec64 *)&now);
+ } else {
+ adj = delta;
+ if (sign)
+ adj |= GEM_BIT(ADDSUB);
+
+ gem_writel(bp, TA, adj);
+ }
+
+ return 0;
+}
+
+static int gem_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
+{
+ struct macb *bp = container_of(ptp, struct macb, ptp_caps);
+
+ gem_tsu_get_time(bp, ts);
+
+ return 0;
+}
+
+static int gem_ptp_settime(struct ptp_clock_info *ptp,
+ const struct timespec64 *ts)
+{
+ struct macb *bp = container_of(ptp, struct macb, ptp_caps);
+
+ gem_tsu_set_time(bp, ts);
+
+ return 0;
+}
+
+static int gem_ptp_enable(struct ptp_clock_info *ptp,
+ struct ptp_clock_request *rq, int on)
+{
+ return -EOPNOTSUPP;
+}
+
+static struct ptp_clock_info gem_ptp_caps_template = {
+ .owner = THIS_MODULE,
+ .name = GEM_PTP_TIMER_NAME,
+ .max_adj = 0,
+ .n_alarm = 0,
+ .n_ext_ts = 0,
+ .n_per_out = 0,
+ .n_pins = 0,
+ .pps = 0,
+ .adjfine = gem_ptp_adjfine,
+ .adjtime = gem_ptp_adjtime,
+ .gettime64 = gem_ptp_gettime,
+ .settime64 = gem_ptp_settime,
+ .enable = gem_ptp_enable,
+};
+
+static void gem_ptp_init_timer(struct macb *bp)
+{
+ struct timespec64 now;
+ u32 rem = 0;
+
+ getnstimeofday64(&now);
+ gem_tsu_set_time(bp, (const struct timespec64 *)&now);
+
+ bp->ns_incr = div_u64_rem(NSEC_PER_SEC, bp->tsu_rate, &rem);
+ if (rem) {
+ u64 adj = rem;
+
+ adj <<= 16; /* 16 bits nsec fragments */
+ bp->subns_incr = div_u64(adj, bp->tsu_rate);
+ } else {
+ bp->subns_incr = 0;
+ }
+
+ gem_writel(bp, TISUBN, GEM_BF(SUBNSINCR, bp->subns_incr));
+ gem_writel(bp, TI, GEM_BF(NSINCR, bp->ns_incr));
+ gem_writel(bp, TA, 0);
+}
+
+static void gem_ptp_clear_timer(struct macb *bp)
+{
+ bp->ns_incr = 0;
+ bp->subns_incr = 0;
+
+ gem_writel(bp, TISUBN, GEM_BF(SUBNSINCR, 0));
+ gem_writel(bp, TI, GEM_BF(NSINCR, 0));
+ gem_writel(bp, TA, 0);
+}
+
+/* While GEM can timestamp PTP packets, it does not mark the RX descriptor
+ * to identify them. UDP packets must be parsed to identify PTP packets.
+ *
+ * Note: Inspired from drivers/net/ethernet/ti/cpts.c
+ */
+static int gem_get_ptp_peer(struct sk_buff *skb, int ptp_class)
+{
+ unsigned int offset = 0;
+ u8 *msgtype, *data = skb->data;
+
+ /* PTP frames are rare! */
+ if (likely(ptp_class == PTP_CLASS_NONE))
+ return -1;
+
+ if (ptp_class & PTP_CLASS_VLAN)
+ offset += VLAN_HLEN;
+
+ switch (ptp_class & PTP_CLASS_PMASK) {
+ case PTP_CLASS_IPV4:
+ offset += ETH_HLEN + IPV4_HLEN(data + offset) + UDP_HLEN;
+ break;
+ case PTP_CLASS_IPV6:
+ offset += ETH_HLEN + IP6_HLEN + UDP_HLEN;
+ break;
+ case PTP_CLASS_L2:
+ offset += ETH_HLEN;
+ break;
+
+ /* something went wrong! */
+ default:
+ return -1;
+ }
+
+ if (skb->len + ETH_HLEN < offset + OFF_PTP_SEQUENCE_ID)
+ return -1;
+
+ if (unlikely(ptp_class & PTP_CLASS_V1))
+ msgtype = data + offset + OFF_PTP_CONTROL;
+ else
+ msgtype = data + offset;
+
+ return (*msgtype) & 0x2;
+}
+
+static void gem_ptp_tx_hwtstamp(struct macb *bp, struct sk_buff *skb,
+ int peer_ev)
+{
+ struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
+ struct timespec64 ts;
+ u64 ns;
+
+ /* PTP Peer Event Frame packets */
+ if (peer_ev) {
+ ts.tv_sec = gem_readl(bp, PEFTSL);
+ ts.tv_nsec = gem_readl(bp, PEFTN);
+
+ /* PTP Event Frame packets */
+ } else {
+ ts.tv_sec = gem_readl(bp, EFTSL);
+ ts.tv_nsec = gem_readl(bp, EFTN);
+ }
+ ns = timespec64_to_ns(&ts);
+
+ memset(shhwtstamps, 0, sizeof(struct skb_shared_hwtstamps));
+ shhwtstamps->hwtstamp = ns_to_ktime(ns);
+ skb_tstamp_tx(skb, skb_hwtstamps(skb));
+}
+
+static void gem_ptp_rx_hwtstamp(struct macb *bp, struct sk_buff *skb,
+ int peer_ev)
+{
+ struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
+ struct timespec64 ts;
+ u64 ns;
+
+ if (peer_ev) {
+ /* PTP Peer Event Frame packets */
+ ts.tv_sec = gem_readl(bp, PEFRSL);
+ ts.tv_nsec = gem_readl(bp, PEFRN);
+ } else {
+ /* PTP Event Frame packets */
+ ts.tv_sec = gem_readl(bp, EFRSL);
+ ts.tv_nsec = gem_readl(bp, EFRN);
+ }
+ ns = timespec64_to_ns(&ts);
+
+ memset(shhwtstamps, 0, sizeof(struct skb_shared_hwtstamps));
+ shhwtstamps->hwtstamp = ns_to_ktime(ns);
+}
+
+/* no static, GEM PTP interface functions */
+void gem_ptp_txstamp(struct macb *bp, struct sk_buff *skb)
+{
+ if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) {
+ int class = ptp_classify_raw(skb);
+ int peer;
+
+ peer = gem_get_ptp_peer(skb, class);
+ if (peer < 0)
+ return;
+
+ /* Timestamp this packet */
+ gem_ptp_tx_hwtstamp(bp, skb, peer);
+ }
+}
+
+void gem_ptp_rxstamp(struct macb *bp, struct sk_buff *skb)
+{
+ int class, peer;
+
+ __skb_push(skb, ETH_HLEN);
+ class = ptp_classify_raw(skb);
+ __skb_pull(skb, ETH_HLEN);
+
+ peer = gem_get_ptp_peer(skb, class);
+ if (peer < 0)
+ return;
+
+ gem_ptp_rx_hwtstamp(bp, skb, peer);
+}
+
+void gem_ptp_init(struct net_device *ndev)
+{
+ struct macb *bp = netdev_priv(ndev);
+
+ spin_lock_init(&bp->tsu_clk_lock);
+ bp->ptp_caps = gem_ptp_caps_template;
+
+ /* nominal frequency and maximum adjustment in ppb */
+ bp->tsu_rate = bp->ptp_info->get_tsu_rate(bp);
+ bp->ptp_caps.max_adj = bp->ptp_info->get_ptp_max_adj();
+
+ gem_ptp_init_timer(bp);
+
+ bp->ptp_clock = ptp_clock_register(&bp->ptp_caps, NULL);
+ if (IS_ERR(&bp->ptp_clock)) {
+ bp->ptp_clock = NULL;
+ pr_err("ptp clock register failed\n");
+ return;
+ }
+
+ dev_info(&bp->pdev->dev, "%s ptp clock registered.\n",
+ GEM_PTP_TIMER_NAME);
+}
+
+void gem_ptp_remove(struct net_device *ndev)
+{
+ struct macb *bp = netdev_priv(ndev);
+
+ if (bp->ptp_clock)
+ ptp_clock_unregister(bp->ptp_clock);
+
+ gem_ptp_clear_timer(bp);
+
+ dev_info(&bp->pdev->dev, "%s ptp clock unregistered.\n",
+ GEM_PTP_TIMER_NAME);
+}
--
2.7.4
^ permalink raw reply related
* [RFC PATCH net-next v4 2/2] macb: Enable 1588 support in SAMA5Dx platforms.
From: Andrei Pistirica @ 2016-12-14 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481720175-12703-1-git-send-email-andrei.pistirica@microchip.com>
This patch does the following:
- Enable HW time stamp for the following platforms: SAMA5D2, SAMA5D3 and
SAMA5D4.
- HW time stamp capabilities are advertised via ethtool and macb ioctl is
updated accordingly.
- HW time stamp on the PTP Ethernet packets are received using the
SO_TIMESTAMPING API. Where timers are obtained from the PTP event/peer
registers.
Note: Patch on net-next, on December 7th.
Signed-off-by: Andrei Pistirica <andrei.pistirica@microchip.com>
---
Patch history:
Version 1:
Integration with SAMA5D2 only. This feature wasn't tested on any
other platform that might use cadence/gem.
Patch is not completely ported to the very latest version of net-next,
and it will be after review.
Version 2 modifications:
- add PTP caps for SAMA5D2/3/4 platforms
- and cosmetic changes
Version 3 modifications:
- add support for sama5D2/3/4 platforms using GEM-PTP interface.
Version 4 modifications:
- time stamp only PTP_V2 events
- maximum adjustment value is set based on Richard's input
Note: Patch on net-next, on December 14th.
drivers/net/ethernet/cadence/macb.c | 168 ++++++++++++++++++++++++++++++++++--
1 file changed, 163 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 538544a..8d5c976 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -714,6 +714,8 @@ static void macb_tx_interrupt(struct macb_queue *queue)
/* First, update TX stats if needed */
if (skb) {
+ gem_ptp_do_txstamp(bp, skb);
+
netdev_vdbg(bp->dev, "skb %u (data %p) TX complete\n",
macb_tx_ring_wrap(bp, tail),
skb->data);
@@ -878,6 +880,8 @@ static int gem_rx(struct macb *bp, int budget)
GEM_BFEXT(RX_CSUM, ctrl) & GEM_RX_CSUM_CHECKED_MASK)
skb->ip_summed = CHECKSUM_UNNECESSARY;
+ gem_ptp_do_rxstamp(bp, skb);
+
bp->stats.rx_packets++;
bp->stats.rx_bytes += skb->len;
@@ -2080,6 +2084,9 @@ static int macb_open(struct net_device *dev)
netif_tx_start_all_queues(dev);
+ if (bp->ptp_info)
+ bp->ptp_info->ptp_init(dev);
+
return 0;
}
@@ -2101,6 +2108,9 @@ static int macb_close(struct net_device *dev)
macb_free_consistent(bp);
+ if (bp->ptp_info)
+ bp->ptp_info->ptp_remove(dev);
+
return 0;
}
@@ -2374,6 +2384,133 @@ static int macb_set_ringparam(struct net_device *netdev,
return 0;
}
+#ifdef CONFIG_MACB_USE_HWSTAMP
+static unsigned int gem_get_tsu_rate(struct macb *bp)
+{
+ /* Note: TSU rate is hardwired to PCLK. */
+ return clk_get_rate(bp->pclk);
+}
+
+static s32 gem_get_ptp_max_adj(void)
+{
+ return 3921508;
+}
+
+static int gem_get_ts_info(struct net_device *dev,
+ struct ethtool_ts_info *info)
+{
+ struct macb *bp = netdev_priv(dev);
+
+ ethtool_op_get_ts_info(dev, info);
+ info->so_timestamping =
+ SOF_TIMESTAMPING_TX_SOFTWARE |
+ SOF_TIMESTAMPING_RX_SOFTWARE |
+ SOF_TIMESTAMPING_SOFTWARE |
+ SOF_TIMESTAMPING_TX_HARDWARE |
+ SOF_TIMESTAMPING_RX_HARDWARE |
+ SOF_TIMESTAMPING_RAW_HARDWARE;
+ info->phc_index = -1;
+
+ if (bp->ptp_clock)
+ info->phc_index = ptp_clock_index(bp->ptp_clock);
+
+ return 0;
+}
+
+static int gem_set_hwtst(struct net_device *netdev,
+ struct ifreq *ifr, int cmd)
+{
+ struct hwtstamp_config config;
+ struct macb *priv = netdev_priv(netdev);
+ u32 regval;
+
+ netdev_vdbg(netdev, "macb_hwtstamp_ioctl\n");
+
+ if (copy_from_user(&config, ifr->ifr_data, sizeof(config)))
+ return -EFAULT;
+
+ /* reserved for future extensions */
+ if (config.flags)
+ return -EINVAL;
+
+ switch (config.tx_type) {
+ case HWTSTAMP_TX_OFF:
+ priv->hwts_tx_en = false;
+ break;
+ case HWTSTAMP_TX_ON:
+ priv->hwts_tx_en = true;
+ break;
+ default:
+ return -ERANGE;
+ }
+
+ switch (config.rx_filter) {
+ case HWTSTAMP_FILTER_NONE:
+ if (priv->hwts_rx_en)
+ priv->hwts_rx_en = false;
+ break;
+ case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_L2_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_L2_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
+ regval = macb_readl(priv, NCR);
+ macb_writel(priv, NCR, (regval | MACB_BIT(SRTSM)));
+
+ if (!priv->hwts_rx_en)
+ priv->hwts_rx_en = true;
+ break;
+ default:
+ config.rx_filter = HWTSTAMP_FILTER_NONE;
+ return -ERANGE;
+ }
+
+ return copy_to_user(ifr->ifr_data, &config, sizeof(config)) ?
+ -EFAULT : 0;
+}
+
+static int gem_get_hwtst(struct net_device *netdev,
+ struct ifreq *ifr)
+{
+ struct hwtstamp_config config;
+ struct macb *priv = netdev_priv(netdev);
+
+ config.flags = 0;
+ config.tx_type = priv->hwts_tx_en ? HWTSTAMP_TX_ON : HWTSTAMP_TX_OFF;
+ config.rx_filter = (priv->hwts_rx_en ?
+ HWTSTAMP_FILTER_ALL : HWTSTAMP_FILTER_NONE);
+
+ return copy_to_user(ifr->ifr_data, &config, sizeof(config)) ?
+ -EFAULT : 0;
+}
+
+static struct macb_ptp_info gem_ptp_info = {
+ .ptp_init = gem_ptp_init,
+ .ptp_remove = gem_ptp_remove,
+ .get_ptp_max_adj = gem_get_ptp_max_adj,
+ .get_tsu_rate = gem_get_tsu_rate,
+ .get_ts_info = gem_get_ts_info,
+ .get_hwtst = gem_get_hwtst,
+ .set_hwtst = gem_set_hwtst,
+};
+#endif
+
+static int macb_get_ts_info(struct net_device *netdev,
+ struct ethtool_ts_info *info)
+{
+ struct macb *bp = netdev_priv(netdev);
+
+ if (bp->ptp_info)
+ return bp->ptp_info->get_ts_info(netdev, info);
+
+ return ethtool_op_get_ts_info(netdev, info);
+}
+
static const struct ethtool_ops macb_ethtool_ops = {
.get_regs_len = macb_get_regs_len,
.get_regs = macb_get_regs,
@@ -2391,7 +2528,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
.get_regs_len = macb_get_regs_len,
.get_regs = macb_get_regs,
.get_link = ethtool_op_get_link,
- .get_ts_info = ethtool_op_get_ts_info,
+ .get_ts_info = macb_get_ts_info,
.get_ethtool_stats = gem_get_ethtool_stats,
.get_strings = gem_get_ethtool_strings,
.get_sset_count = gem_get_sset_count,
@@ -2404,6 +2541,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct phy_device *phydev = dev->phydev;
+ struct macb *bp = netdev_priv(dev);
if (!netif_running(dev))
return -EINVAL;
@@ -2411,7 +2549,20 @@ static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
if (!phydev)
return -ENODEV;
- return phy_mii_ioctl(phydev, rq, cmd);
+ switch (cmd) {
+ case SIOCSHWTSTAMP:
+ if (bp->ptp_info)
+ return bp->ptp_info->set_hwtst(dev, rq, cmd);
+
+ return -EOPNOTSUPP;
+ case SIOCGHWTSTAMP:
+ if (bp->ptp_info)
+ return bp->ptp_info->get_hwtst(dev, rq);
+
+ return -EOPNOTSUPP;
+ default:
+ return phy_mii_ioctl(phydev, rq, cmd);
+ }
}
static int macb_set_features(struct net_device *netdev,
@@ -2485,6 +2636,12 @@ static void macb_configure_caps(struct macb *bp,
dcfg = gem_readl(bp, DCFG2);
if ((dcfg & (GEM_BIT(RX_PKT_BUFF) | GEM_BIT(TX_PKT_BUFF))) == 0)
bp->caps |= MACB_CAPS_FIFO_MODE;
+
+ /* iff HWSTAMP is configure and gem has the capability */
+#ifdef CONFIG_MACB_USE_HWSTAMP
+ if (gem_has_ptp(bp))
+ bp->ptp_info = &gem_ptp_info;
+#endif
}
dev_dbg(&bp->pdev->dev, "Cadence caps 0x%08x\n", bp->caps);
@@ -3041,7 +3198,7 @@ static const struct macb_config pc302gem_config = {
};
static const struct macb_config sama5d2_config = {
- .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
+ .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII | MACB_CAPS_GEM_HAS_PTP,
.dma_burst_length = 16,
.clk_init = macb_clk_init,
.init = macb_init,
@@ -3049,14 +3206,15 @@ static const struct macb_config sama5d2_config = {
static const struct macb_config sama5d3_config = {
.caps = MACB_CAPS_SG_DISABLED | MACB_CAPS_GIGABIT_MODE_AVAILABLE
- | MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
+ | MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII
+ | MACB_CAPS_GEM_HAS_PTP,
.dma_burst_length = 16,
.clk_init = macb_clk_init,
.init = macb_init,
};
static const struct macb_config sama5d4_config = {
- .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
+ .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII | MACB_CAPS_GEM_HAS_PTP,
.dma_burst_length = 4,
.clk_init = macb_clk_init,
.init = macb_init,
--
2.7.4
^ permalink raw reply related
* [PATCH linux v1 0/4] Seven segment display support
From: Greg KH @ 2016-12-14 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214134530.2bd54a4e@free-electrons.com>
On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
> Natarajan wrote:
>
> > Documentation for the binding which provides an interface for adding clock,
> > data and clear signal GPIO lines to control seven segment display.
> >
> > The platform device driver provides an API for displaying on two 7-segment
> > displays, and implements the required bit-banging. The hardware assumed is
> > 74HC164 wired to two 7-segment displays.
> >
> > The character device driver implements the user-space API for letting a user
> > write to two 7-segment displays including any conversion methods necessary
> > to map the user input to two 7-segment displays.
> >
> > Adding clock, data and clear signal GPIO lines in the devicetree to control
> > seven segment display on zaius platform.
> >
> > The platform driver matches on the device tree node; the platform driver also
> > initializes the character device.
> >
> > Tested that the seven segment display works properly by writing to the
> > character device file on a EVB AST2500 board which also has 74HC164 wired
> > to two 7-segment displays.
>
> FWIW, I proposed a driver for seven segment displays back in 2013:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
>
> And the feedback from Greg KH was: we don't need a driver for that, do
> it from userspace. See:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
>
> So: good luck :-)
Did anyone ever write a library for this type of thing?
Again, I don't want to see one-off drivers for random devices like this
that should be able to all be controlled from userspace in a common
manner. Much like we did for fingerprint readers a long long time
ago...
thanks,
greg k-h
^ permalink raw reply
* [PATCH 0/2] video/sti/cec: add HDMI notifier support
From: Benjamin Gaignard @ 2016-12-14 12:57 UTC (permalink / raw)
To: linux-arm-kernel
Following (copying !) what Hans have done in this serie of patches
http://www.spinics.net/lists/linux-media/msg109141.html
I have implemented hdmi notifier in hdmi controled and stih-cec drivers.
Those patches should be applied on top of Hans patches for exynos.
I have tested hdmi notifier by pluging/unpluging HDMI cable and check
the value of the physical address with "cec-ctl --tuner".
"cec-compliance -A" is also functional.
Hans, I haven't move stih-cec out of staging because I don't have the
exact branch to test it, can you do the move for stih-cec after applying
those patches ?
Regards,
Benjamin
Benjamin Gaignard (2):
sti: hdmi: add HDMI notifier support
stih-cec: add hdmi-notifier support
.../devicetree/bindings/media/stih-cec.txt | 2 ++
arch/arm/boot/dts/stih407-family.dtsi | 12 ---------
arch/arm/boot/dts/stih410.dtsi | 15 ++++++++++-
drivers/gpu/drm/sti/Kconfig | 1 +
drivers/gpu/drm/sti/sti_hdmi.c | 15 +++++++++++
drivers/gpu/drm/sti/sti_hdmi.h | 2 ++
drivers/staging/media/st-cec/Kconfig | 1 +
drivers/staging/media/st-cec/stih-cec.c | 29 +++++++++++++++++++++-
8 files changed, 63 insertions(+), 14 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] sti: hdmi: add HDMI notifier support
From: Benjamin Gaignard @ 2016-12-14 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481720229-7587-1-git-send-email-benjamin.gaignard@linaro.org>
Implement the HDMI notifier support to allow CEC drivers to
be informed when there is a new EDID and when a connect or
disconnect happens.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
drivers/gpu/drm/sti/Kconfig | 1 +
drivers/gpu/drm/sti/sti_hdmi.c | 15 +++++++++++++++
drivers/gpu/drm/sti/sti_hdmi.h | 2 ++
3 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index acd7286..59ceffc 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -8,5 +8,6 @@ config DRM_STI
select DRM_PANEL
select FW_LOADER
select SND_SOC_HDMI_CODEC if SND_SOC
+ select HDMI_NOTIFIERS
help
Choose this option to enable DRM on STM stiH4xx chipset
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 376b076..6667371 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -786,6 +786,8 @@ static void sti_hdmi_disable(struct drm_bridge *bridge)
clk_disable_unprepare(hdmi->clk_pix);
hdmi->enabled = false;
+
+ hdmi_event_disconnect(hdmi->notifier);
}
static void sti_hdmi_pre_enable(struct drm_bridge *bridge)
@@ -892,6 +894,10 @@ static int sti_hdmi_connector_get_modes(struct drm_connector *connector)
if (!edid)
goto fail;
+ hdmi_event_connect(hdmi->notifier);
+ hdmi_event_new_edid(hdmi->notifier, edid,
+ EDID_LENGTH * (edid->extensions + 1));
+
count = drm_add_edid_modes(connector, edid);
drm_mode_connector_update_edid_property(connector, edid);
drm_edid_to_eld(connector, edid);
@@ -949,10 +955,12 @@ struct drm_connector_helper_funcs sti_hdmi_connector_helper_funcs = {
if (hdmi->hpd) {
DRM_DEBUG_DRIVER("hdmi cable connected\n");
+ hdmi_event_connect(hdmi->notifier);
return connector_status_connected;
}
DRM_DEBUG_DRIVER("hdmi cable disconnected\n");
+ hdmi_event_disconnect(hdmi->notifier);
return connector_status_disconnected;
}
@@ -1464,6 +1472,10 @@ static int sti_hdmi_probe(struct platform_device *pdev)
goto release_adapter;
}
+ hdmi->notifier = hdmi_notifier_get(&pdev->dev);
+ if (!hdmi->notifier)
+ goto release_adapter;
+
hdmi->reset = devm_reset_control_get(dev, "hdmi");
/* Take hdmi out of reset */
if (!IS_ERR(hdmi->reset))
@@ -1483,11 +1495,14 @@ static int sti_hdmi_remove(struct platform_device *pdev)
{
struct sti_hdmi *hdmi = dev_get_drvdata(&pdev->dev);
+ hdmi_event_disconnect(hdmi->notifier);
+
i2c_put_adapter(hdmi->ddc_adapt);
if (hdmi->audio_pdev)
platform_device_unregister(hdmi->audio_pdev);
component_del(&pdev->dev, &sti_hdmi_ops);
+ hdmi_notifier_put(hdmi->notifier);
return 0;
}
diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
index 119bc35..70aac98 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.h
+++ b/drivers/gpu/drm/sti/sti_hdmi.h
@@ -8,6 +8,7 @@
#define _STI_HDMI_H_
#include <linux/hdmi.h>
+#include <linux/hdmi-notifier.h>
#include <linux/platform_device.h>
#include <drm/drmP.h>
@@ -102,6 +103,7 @@ struct sti_hdmi {
struct platform_device *audio_pdev;
struct hdmi_audio_params audio;
struct drm_connector *drm_connector;
+ struct hdmi_notifier *notifier;
};
u32 hdmi_read(struct sti_hdmi *hdmi, int offset);
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] stih-cec: add hdmi-notifier support
From: Benjamin Gaignard @ 2016-12-14 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481720229-7587-1-git-send-email-benjamin.gaignard@linaro.org>
By using the HDMI notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.
Update the bindings documenting the new hdmi phandle and
update stih410.dtsi and stih407-family.dtsi accordingly.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
.../devicetree/bindings/media/stih-cec.txt | 2 ++
arch/arm/boot/dts/stih407-family.dtsi | 12 ---------
arch/arm/boot/dts/stih410.dtsi | 15 ++++++++++-
drivers/staging/media/st-cec/Kconfig | 1 +
drivers/staging/media/st-cec/stih-cec.c | 29 +++++++++++++++++++++-
5 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt b/Documentation/devicetree/bindings/media/stih-cec.txt
index 71c4b2f..7d82121 100644
--- a/Documentation/devicetree/bindings/media/stih-cec.txt
+++ b/Documentation/devicetree/bindings/media/stih-cec.txt
@@ -9,6 +9,7 @@ Required properties:
- pinctrl-names: Contains only one value - "default"
- pinctrl-0: Specifies the pin control groups used for CEC hardware.
- resets: Reference to a reset controller
+ - st,hdmi-handle: Phandle to the HMDI controller
Example for STIH407:
@@ -22,4 +23,5 @@ sti-cec at 094a087c {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cec0_default>;
resets = <&softreset STIH407_LPM_SOFTRESET>;
+ st,hdmi-handle = <&hdmi>;
};
diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 8f79b41..ef7c79a 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -756,18 +756,6 @@
<&clk_s_c0_flexgen CLK_ETH_PHY>;
};
- cec: sti-cec at 094a087c {
- compatible = "st,stih-cec";
- reg = <0x94a087c 0x64>;
- clocks = <&clk_sysin>;
- clock-names = "cec-clk";
- interrupts = <GIC_SPI 140 IRQ_TYPE_NONE>;
- interrupt-names = "cec-irq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_cec0_default>;
- resets = <&softreset STIH407_LPM_SOFTRESET>;
- };
-
rng10: rng at 08a89000 {
compatible = "st,rng";
reg = <0x08a89000 0x1000>;
diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index a3ef734..c98d86e 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -193,7 +193,7 @@
<&clk_s_d2_quadfs 0>;
};
- sti-hdmi at 8d04000 {
+ hdmi: sti-hdmi at 8d04000 {
compatible = "st,stih407-hdmi";
reg = <0x8d04000 0x1000>;
reg-names = "hdmi-reg";
@@ -259,5 +259,18 @@
clocks = <&clk_sysin>;
interrupts = <GIC_SPI 205 IRQ_TYPE_EDGE_RISING>;
};
+
+ sti-cec at 094a087c {
+ compatible = "st,stih-cec";
+ reg = <0x94a087c 0x64>;
+ clocks = <&clk_sysin>;
+ clock-names = "cec-clk";
+ interrupts = <GIC_SPI 140 IRQ_TYPE_NONE>;
+ interrupt-names = "cec-irq";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_cec0_default>;
+ resets = <&softreset STIH407_LPM_SOFTRESET>;
+ st,hdmi-handle = <&hdmi>;
+ };
};
};
diff --git a/drivers/staging/media/st-cec/Kconfig b/drivers/staging/media/st-cec/Kconfig
index 784d2c6..3072387 100644
--- a/drivers/staging/media/st-cec/Kconfig
+++ b/drivers/staging/media/st-cec/Kconfig
@@ -1,6 +1,7 @@
config VIDEO_STI_HDMI_CEC
tristate "STMicroelectronics STiH4xx HDMI CEC driver"
depends on VIDEO_DEV && MEDIA_CEC && (ARCH_STI || COMPILE_TEST)
+ select HDMI_NOTIFIERS
---help---
This is a driver for STIH4xx HDMI CEC interface. It uses the
generic CEC framework interface.
diff --git a/drivers/staging/media/st-cec/stih-cec.c b/drivers/staging/media/st-cec/stih-cec.c
index 2143448..ce94097 100644
--- a/drivers/staging/media/st-cec/stih-cec.c
+++ b/drivers/staging/media/st-cec/stih-cec.c
@@ -10,11 +10,13 @@
* (at your option) any later version.
*/
#include <linux/clk.h>
+#include <linux/hdmi-notifier.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/mfd/syscon.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_platform.h>
#include <linux/platform_device.h>
#include <linux/version.h>
@@ -130,6 +132,7 @@ struct stih_cec {
void __iomem *regs;
int irq;
u32 irq_status;
+ struct hdmi_notifier *notifier;
};
static int stih_cec_adap_enable(struct cec_adapter *adap, bool enable)
@@ -304,12 +307,29 @@ static int stih_cec_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct resource *res;
struct stih_cec *cec;
+ struct device_node *np;
+ struct platform_device *hdmi_dev;
int ret;
cec = devm_kzalloc(dev, sizeof(*cec), GFP_KERNEL);
if (!cec)
return -ENOMEM;
+ np = of_parse_phandle(pdev->dev.of_node, "st,hdmi-handle", 0);
+
+ if (!np) {
+ dev_err(&pdev->dev, "Failed to find hdmi node in device tree\n");
+ return -ENODEV;
+ }
+
+ hdmi_dev = of_find_device_by_node(np);
+ if (!hdmi_dev)
+ return -EPROBE_DEFER;
+
+ cec->notifier = hdmi_notifier_get(&hdmi_dev->dev);
+ if (!cec->notifier)
+ return -ENOMEM;
+
cec->dev = dev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -336,7 +356,7 @@ static int stih_cec_probe(struct platform_device *pdev)
cec->adap = cec_allocate_adapter(&sti_cec_adap_ops, cec,
CEC_NAME,
CEC_CAP_LOG_ADDRS | CEC_CAP_PASSTHROUGH |
- CEC_CAP_PHYS_ADDR | CEC_CAP_TRANSMIT,
+ CEC_CAP_TRANSMIT,
1, &pdev->dev);
ret = PTR_ERR_OR_ZERO(cec->adap);
if (ret)
@@ -348,12 +368,19 @@ static int stih_cec_probe(struct platform_device *pdev)
return ret;
}
+ cec_register_hdmi_notifier(cec->adap, cec->notifier);
+
platform_set_drvdata(pdev, cec);
return 0;
}
static int stih_cec_remove(struct platform_device *pdev)
{
+ struct stih_cec *cec = platform_get_drvdata(pdev);
+
+ cec_unregister_adapter(cec->adap);
+ hdmi_notifier_put(cec->notifier);
+
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v6 1/8] MFD: add bindings for STM32 Timers driver
From: Benjamin Gaignard @ 2016-12-14 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+qzhUAMG_jL6CSHz+kHu6M6N8Nko4KfRQRgRgtk-KTKg@mail.gmail.com>
2016-12-13 22:07 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Tue, Dec 13, 2016 at 3:29 AM, Benjamin Gaignard
> <benjamin.gaignard@linaro.org> wrote:
>> 2016-12-12 19:51 GMT+01:00 Rob Herring <robh@kernel.org>:
>>> On Fri, Dec 09, 2016 at 03:15:12PM +0100, Benjamin Gaignard wrote:
>>>> Add bindings information for STM32 Timers
>>>>
>>>> version 6:
>>>> - rename stm32-gtimer to stm32-timers
>>>> - change compatible
>>>> - add description about the IPs
>>>>
>>>> version 2:
>>>> - rename stm32-mfd-timer to stm32-gptimer
>>>> - only keep one compatible string
>>>>
>>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>> ---
>>>> .../devicetree/bindings/mfd/stm32-timers.txt | 46 ++++++++++++++++++++++
>>>> 1 file changed, 46 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
>>>> new file mode 100644
>>>> index 0000000..b30868e
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
>>>> @@ -0,0 +1,46 @@
>>>> +STM32 Timers driver bindings
>>>> +
>>>> +This IP provides 3 types of timer along with PWM functionality:
>>>> +- advanced-control timers consist of a 16-bit auto-reload counter driven by a programmable
>>>> + prescaler, break input feature, PWM outputs and complementary PWM ouputs channels.
>>>> +- general-purpose timers consist of a 16-bit or 32-bit auto-reload counter driven by a
>>>> + programmable prescaler and PWM outputs.
>>>> +- basic timers consist of a 16-bit auto-reload counter driven by a programmable prescaler.
>>>> +
>>>> +Required parameters:
>>>> +- compatible: must be "st,stm32-timers"
>>>> +
>>>> +- reg: Physical base address and length of the controller's
>>>> + registers.
>>>> +- clock-names: Set to "clk_int".
>>>
>>> 'clk' is redundant. Also, you don't really need -names when there is
>>> only one of them.
>>
>> I use devm_regmap_init_mmio_clk() which get the clock by it name so
>> I have to define it in DT.
>
> Are you sure NULL is not allowed? I don't know, but at least clk_get()
> allows NULL.
regmap_mmio_gen_context() doesn't call clk_get() if the clock name isn't set:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/base/regmap/regmap-mmio.c?id=refs/tags/v4.9#n308
so clock-names field is really needed.
> It's fine to keep, just drop the "clk_" part.
ok
>
>>
>>>> +- clocks: Phandle to the clock used by the timer module.
>>>> + For Clk properties, please refer to ../clock/clock-bindings.txt
>>>> +
>>>> +Optional parameters:
>>>> +- resets: Phandle to the parent reset controller.
>>>> + See ../reset/st,stm32-rcc.txt
>>>> +
>>>> +Optional subnodes:
>>>> +- pwm: See ../pwm/pwm-stm32.txt
>>>> +- timer: See ../iio/timer/stm32-timer-trigger.txt
>>>> +
>>>> +Example:
>>>> + timers at 40010000 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + compatible = "st,stm32-timers";
>>>> + reg = <0x40010000 0x400>;
>>>> + clocks = <&rcc 0 160>;
>>>> + clock-names = "clk_int";
>>>> +
>>>> + pwm {
>>>> + compatible = "st,stm32-pwm";
>>>> + pinctrl-0 = <&pwm1_pins>;
>>>> + pinctrl-names = "default";
>>>> + };
>>>> +
>>>> + timer {
>>>> + compatible = "st,stm32-timer-trigger";
>>>> + reg = <0>;
>>>
>>> You don't need reg here as there is only one. In turn, you don't need
>>> #address-cells or #size-cells.
>>
>> I use "reg" to set each timer configuration.
>> From hardware point of view they are all the same except for which hardware
>> signals they could consume and/or send.
>
> This sounds okay, but...
>
>> "reg" is used as index of the two tables in driver code.
>
> this statement doesn't really sound like valid use of reg.
>
> If you keep reg, then the node needs a unit address (timer at 0).
I will do that in next version but I will wait for other maintainers (PWM/IIO)
remarks before send it
Thanks
Benjamin
>
> Rob
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH linux v1 0/4] Seven segment display support
From: Neil Armstrong @ 2016-12-14 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214125641.GA5379@kroah.com>
On 12/14/2016 01:56 PM, Greg KH wrote:
> On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
>> Natarajan wrote:
>>
>>> Documentation for the binding which provides an interface for adding clock,
>>> data and clear signal GPIO lines to control seven segment display.
>>>
>>> The platform device driver provides an API for displaying on two 7-segment
>>> displays, and implements the required bit-banging. The hardware assumed is
>>> 74HC164 wired to two 7-segment displays.
>>>
>>> The character device driver implements the user-space API for letting a user
>>> write to two 7-segment displays including any conversion methods necessary
>>> to map the user input to two 7-segment displays.
>>>
>>> Adding clock, data and clear signal GPIO lines in the devicetree to control
>>> seven segment display on zaius platform.
>>>
>>> The platform driver matches on the device tree node; the platform driver also
>>> initializes the character device.
>>>
>>> Tested that the seven segment display works properly by writing to the
>>> character device file on a EVB AST2500 board which also has 74HC164 wired
>>> to two 7-segment displays.
>>
>> FWIW, I proposed a driver for seven segment displays back in 2013:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
>>
>> And the feedback from Greg KH was: we don't need a driver for that, do
>> it from userspace. See:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
>>
>> So: good luck :-)
>
> Did anyone ever write a library for this type of thing?
>
> Again, I don't want to see one-off drivers for random devices like this
> that should be able to all be controlled from userspace in a common
> manner. Much like we did for fingerprint readers a long long time
> ago...
>
> thanks,
>
> greg k-h
Hi Greg,
Actually, it's more than a random interface, a lot of SoCs and boards actually have such displays
and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly stuff to only print a few
characters a simple and clean driver could achieve.
Some very well known SoCs even have integrated registers to lower the BOM and bypass the need for
a 74HC164 like component and avoid gpio bit banging.
My personal concern is that you could also need to drive more segments, thus 7-segments
is too restrictive.
But this driver is well structured, the gpio-bitbanging sub-driver is welcome.
Neil
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-14 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <26ffeee4-ff43-b3d3-3267-5fcbc50e2974@osg.samsung.com>
On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> Hello Bartlomiej,
Hi,
> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> > Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> > (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> > cooling maps to account for new OPPs.
> >
> > Since new OPPs are not available on all Exynos5422/5800 boards modify
> > dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> > Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >
> > Tested on Odroid-XU3 and XU3 Lite.
> >
> > Cc: Doug Anderson <dianders@chromium.org>
> > Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> > Cc: Andreas Faerber <afaerber@suse.de>
> > Cc: Thomas Abraham <thomas.ab@samsung.com>
> > Cc: Ben Gamari <ben@smart-cactus.org>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > ---
> > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> > arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> > arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> > arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> > 4 files changed, 43 insertions(+), 7 deletions(-)
> >
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> > @@ -118,7 +118,7 @@
> > /*
> > * When reaching cpu_alert3, reduce CPU
> > * by 2 steps. On Exynos5422/5800 that would
> > - * be: 1600 MHz and 1100 MHz.
> > + * (usually) be: 1800 MHz and 1200 MHz.
> > */
> > map3 {
> > trip = <&cpu_alert3>;
> > @@ -131,16 +131,16 @@
> >
> > /*
> > * When reaching cpu_alert4, reduce CPU
> > - * further, down to 600 MHz (11 steps for big,
> > - * 7 steps for LITTLE).
> > + * further, down to 600 MHz (13 steps for big,
> > + * 8 steps for LITTLE).
> > */
> > - map5 {
> > + cooling_map5: map5 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu0 3 7>;
> > + cooling-device = <&cpu0 3 8>;
> > };
> > - map6 {
> > + cooling_map6: map6 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu4 3 11>;
> > + cooling-device = <&cpu4 3 13>;
> > };
> > };
> > };
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> > @@ -21,6 +21,23 @@
> > compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> > };
> >
> > +&cluster_a15_opp_table {
> > + /delete-node/opp at 2000000000;
> > + /delete-node/opp at 1900000000;
> > +};
> > +
> > +&cluster_a7_opp_table {
> > + /delete-node/opp at 1400000000;
> > +};
> > +
>
> I think that a comment in the DTS why these operating points aren't available
> in this board will make more clear why the nodes are being deleted.
Ok, I will add these comments in the next patch revision.
> > +&cooling_map5 {
> > + cooling-device = <&cpu0 3 7>;
> > +};
> > +
> > +&cooling_map6 {
> > + cooling-device = <&cpu4 3 11>;
> > +};
> > +
> > &pwm {
> > /*
> > * PWM 0 -- fan
> > Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > @@ -146,6 +146,10 @@
> > vdd-supply = <&ldo9_reg>;
> > };
> >
> > +&cluster_a7_opp_table {
> > + /delete-property/opp at 1400000000;
> > +};
> > +
> > &cpu0 {
> > cpu-supply = <&buck2_reg>;
> > };
> > Index: b/arch/arm/boot/dts/exynos5800.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > @@ -24,6 +24,16 @@
> > };
> >
> > &cluster_a15_opp_table {
> > + opp at 2000000000 {
> > + opp-hz = /bits/ 64 <2000000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > + opp at 1900000000 {
> > + opp-hz = /bits/ 64 <1900000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > opp at 1700000000 {
> > opp-microvolt = <1250000>;
> > };
> > @@ -85,6 +95,11 @@
> > };
> >
>
> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> INT rail would need to be scaled up as well since there's a maximum voltage
> difference between the ARM and INT rails before the system becomes unstable:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> https://lkml.org/lkml/2014/5/2/419
>
> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> the maximum voltage skew is between a limit. But that never made to mainline:
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> https://lkml.org/lkml/2014/4/29/28
>
> Did that change and there's infrastructure in mainline now to cope with that?
> If that's the case, I think it would be good to mention in the commit message.
I was not aware of this limitation and AFAIK mainline has currently
no code to handle it. I also cannot find any code to handle this in
Hardkernel's vendor kernel for Odroid-XU3 board.
Do you know whether this problem exists also on Exynos5422/5800
SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
regulator code also on Exynos5800 SoC based Peach Pi board but was
the problem actually present on this board?
[ I added Arjun to Cc:, maybe he can help in explaining this issue
(unfortunately Inderpal's email is no longer working). ]
Please also note that on Exynos5422/5800 SoCs the same ARM rail
voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
IOW if the problem exists it is already present in the mainline
kernel.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]
From: Sebastian Reichel @ 2016-12-14 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214125323.GA4951@amd>
Hi Pali & Pavel,
On Wed, Dec 14, 2016 at 01:53:23PM +0100, Pavel Machek wrote:
> > > [ 220.248596] tty ttyO1: Radio packet sent
> > > [ 220.249328] Bluetooth: hci0: Frame reassembly failed (-84)
> > > [ 220.272949] tty ttyO1: wakeup received: 1 -> 0
> > > [ 221.283477] tty ttyO1: radio packet timeout!
> > > [ 221.283630] enqueue: hu c304cc80 skb cd4a9b40
> > > [ 223.363372] Bluetooth: hci0 command 0xfc18 tx timeout
> > > pavel at n900:~$
> >
> > In log are still some failures, but ... is bluetooth working now?
I could scan for devices. The code is still racy, though. It's
most likely related to the newly introduced idle code. (Without
sending the BT module to correctly idle the bcm2048 does not
work correctly at all)
I was quite busy the last few weeks and did not manage to find
much time for kernel work. Now I will first have to catch up
with my power-supply tree.
> It is... for Sebastian. I'm playing with camera now.
>
> > I see that you applied this patch:
> > https://git.kernel.org/cgit/linux/kernel/git/pavel/linux-n900.git/commit/?id=051aa3fbf03ac770d8344690f5a936a7f04c6884
> >
> > Looks like that pinmux is in DTS file incorrect. Can somebody verify it?
> > Maybe Tony?
>
> Yes, it is. Sebastian was pretty certain about that.
Yes, I'm certain. The bootloader enables the pullup resistors.
Note, that the wrong DTS entry is not in mainline. My bluetooth
branch has a fixed DTS patch instead of a fixup patch on top of
the broken one:
https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/commit/?h=nokia-bluetooth-dev&id=6b63c111a979d100cfbdd76cb4a6bbadace35216
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/28d87fe2/attachment.sig>
^ permalink raw reply
* [PATCHv6] support for AD5820 camera auto-focus coil
From: Pali Rohár @ 2016-12-14 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160808214132.GB2946@xo-6d-61-c0.localdomain>
On Monday 08 August 2016 23:41:32 Pavel Machek wrote:
> On Mon 2016-08-08 11:09:56, Sakari Ailus wrote:
> > On Fri, Aug 05, 2016 at 12:26:11PM +0200, Pavel Machek wrote:
> > > This adds support for AD5820 autofocus coil, found for example in
> > > Nokia N900 smartphone.
> >
> > Thanks, Pavel!
> >
> > Let's use V4L2_CID_FOCUS_ABSOLUTE, as is in the patch. If we get
> > something better in the future, we'll switch to that then.
> >
> > I've applied this to ad5820 branch in my tree.
>
> Thanks. If I understands things correctly, both DTS patch and this
> patch are waiting in your tree, so we should be good to go for 4.9
> (unless some unexpected problems surface)?
>
> Best regards,
> Pavel
Was DTS patch merged into 4.9? At least I do not see updated that dts
file omap3-n900.dts in linus tree...
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/d8addaf7/attachment-0001.sig>
^ permalink raw reply
* [PATCH 2/2] ARM: soft-reboot into same mode that we entered the kernel
From: Marc Zyngier @ 2016-12-14 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214120541.GD14217@n2100.armlinux.org.uk>
On 14/12/16 12:05, Russell King - ARM Linux wrote:
> On Wed, Dec 14, 2016 at 11:56:49AM +0000, Mark Rutland wrote:
>> On Wed, Dec 14, 2016 at 10:46:35AM +0000, Russell King wrote:
>>> When we soft-reboot (eg, kexec) from one kernel into the next, we need
>>> to ensure that we enter the new kernel in the same processor mode as
>>> when we were entered, so that (eg) the new kernel can install its own
>>> hypervisor - the old kernel's hypervisor will have been overwritten.
>>>
>>> In order to do this, we need to pass a flag to cpu_reset() so it knows
>>> what to do, and we need to modify the kernel's own hypervisor stub to
>>> allow it to handle a soft-reboot.
>>>
>>> As we are always guaranteed to install our own hypervisor if we're
>>> entered in HYP32 mode, and KVM will have moved itself out of the way
>>> on kexec/normal reboot, we can assume that our hypervisor is in place
>>> when we want to kexec, so changing our hypervisor API should not be a
>>> problem.
>>
>> Just to check, does that also hold true for kdump?
>>
>> I haven't gone digging yet, but it looks like KVM might still be
>> installed, rather than the hyp stub, and we might need some logic to
>> ensure that it's torn down...
>
> The same problem will be true of ARM64 - I don't see any solution to
> that in the present state.
>
>>> @@ -51,7 +52,9 @@ static void __soft_restart(void *addr)
>>>
>>> /* Switch to the identity mapping. */
>>> phys_reset = (phys_reset_t)virt_to_idmap(cpu_reset);
>>> - phys_reset((unsigned long)addr);
>>> +
>>> + /* original stub should be restored by kvm */
>>> + phys_reset((unsigned long)addr, is_hyp_mode_available());
>>
>> ... otherwise here we'd call into the KVM hyp code in a potentially
>> confusing manner.
>>
>> Otherwise, this looks fine to me.
>
> The only thing that I can think which would resolve that would be to
> lay down a standard API for the hyp code, so things like reboot into
> hyp mode can work irrespective of the hyp stub in place.
That looks like a sensible thing to do. I'll look into it.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
From: Mark Rutland @ 2016-12-14 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3a6ac655-bfa6-0d90-6351-731ce36e99eb@redhat.com>
Hi,
On Wed, Dec 14, 2016 at 05:51:05PM +0530, Pratyush Anand wrote:
>
> On Wednesday 14 December 2016 05:07 PM, Mark Rutland wrote:
> >I see in an earlier message that the need for sha256 was being discussed
> >in another thread. Do either of you happen to have a pointer to that.
>
> patch 0/2 of this series.
AFAICT, that just says the the existing sha256 check is slow, not *why*
a sha256 check of some description is necessary. I'm still at a loss as
to why it is considered necessary, rather than being a debugging aid or
sanity check.
> >To me, it seems like it doesn't come with much benefit for the kdump
> >case given that's best-effort anyway, and as above the verification code
> >could have been be corrupted. In the non-kdump case it's not strictly
> >necessary and seems like a debugging aid rather than a necessary piece
> >of functionality -- if that's the case, a 20 second delay isn't the end
> >of the world...
>
> Even for the non-kdump ie `kexec -l` case we do not have a
> functionality to bypass sha verification in kexec-tools. --lite
> option with the kexec-tools was discouraged and not accepted.
Ok. Do you have a pointer to the thread regarding that, for context?
> So,it is 20s for both `kexec -l` and `kexec -p`.
Well, unless we can have a --{no-,}sha-check, and make the default NO
for arm64.
> Also other arch like x86_64 takes negligible time in sha verification.
That's certainly an argument for not changing the other architectures,
but given it's slow for arm64, we could have a different default...
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot
From: Chen-Yu Tsai @ 2016-12-14 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213164742.4ztisstxifatlm5a@sirena.org.uk>
On Wed, Dec 14, 2016 at 12:47 AM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Dec 09, 2016 at 11:20:18AM +0000, Lee Jones wrote:
>
>> Is the following valid/necessary?
>
>> On Wed, 23 Nov 2016, Chen-Yu Tsai wrote:
>> > The AXP806 supports either master/standalone or slave mode.
>> > Slave mode allows sharing the serial bus, even with multiple
>> > AXP806 which all have the same hardware address.
>
>> > This is done with extra "serial interface address extension",
>> > or AXP806_BUS_ADDR_EXT, and "register address extension", or
>> > AXP806_REG_ADDR_EXT, registers. The former is read-only, with
>> > 1 bit customizable at the factory, and 1 bit depending on the
>
> I don't really know anything about the details of this chip, sorry.
If these 2 registers don't match, any access to the other registers
is ignored, so the kernel either read bogus data, or the read fails.
What this patch does is make sure the registers match, to guarantee
access, and then reinitialize the regmap cache to get rid of any
stale data.
>> > This patch sets AXP806_REG_ADDR_EXT to 0x10, which is what we
>> > know to be the proper value for a standard AXP806 in slave mode.
>> > Afterwards it will reinitialize the regmap cache, to purge any
>> > invalid stale values.
>
> If the chip has been reset then you'd want to reset the cache too. I've
> no idea if that's needed here or not though, it depends what happens to
> the global state of the chip when this reconfiguration happens.
It is not a reset in the general sense. I suppose a better way would
be to do an explicit write to the register first, then initialize
the regmap. I'd have to export the write function from the RSB bus
driver first though.
Regards
ChenYu
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-14 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2340115.HEG9AYUCMD@amdc3058>
Hello Bartlomiej,
On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>
> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>> Hello Bartlomiej,
>
> Hi,
>
>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>> cooling maps to account for new OPPs.
>>>
>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>
>>> Tested on Odroid-XU3 and XU3 Lite.
>>>
>>> Cc: Doug Anderson <dianders@chromium.org>
>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>>> Cc: Andreas Faerber <afaerber@suse.de>
>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
>>> Cc: Ben Gamari <ben@smart-cactus.org>
>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>
>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>> @@ -118,7 +118,7 @@
>>> /*
>>> * When reaching cpu_alert3, reduce CPU
>>> * by 2 steps. On Exynos5422/5800 that would
>>> - * be: 1600 MHz and 1100 MHz.
>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>> */
>>> map3 {
>>> trip = <&cpu_alert3>;
>>> @@ -131,16 +131,16 @@
>>>
>>> /*
>>> * When reaching cpu_alert4, reduce CPU
>>> - * further, down to 600 MHz (11 steps for big,
>>> - * 7 steps for LITTLE).
>>> + * further, down to 600 MHz (13 steps for big,
>>> + * 8 steps for LITTLE).
>>> */
>>> - map5 {
>>> + cooling_map5: map5 {
>>> trip = <&cpu_alert4>;
>>> - cooling-device = <&cpu0 3 7>;
>>> + cooling-device = <&cpu0 3 8>;
>>> };
>>> - map6 {
>>> + cooling_map6: map6 {
>>> trip = <&cpu_alert4>;
>>> - cooling-device = <&cpu4 3 11>;
>>> + cooling-device = <&cpu4 3 13>;
>>> };
>>> };
>>> };
>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>> @@ -21,6 +21,23 @@
>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>> };
>>>
>>> +&cluster_a15_opp_table {
>>> + /delete-node/opp at 2000000000;
>>> + /delete-node/opp at 1900000000;
>>> +};
>>> +
>>> +&cluster_a7_opp_table {
>>> + /delete-node/opp at 1400000000;
>>> +};
>>> +
>>
>> I think that a comment in the DTS why these operating points aren't available
>> in this board will make more clear why the nodes are being deleted.
>
> Ok, I will add these comments in the next patch revision.
>
>>> +&cooling_map5 {
>>> + cooling-device = <&cpu0 3 7>;
>>> +};
>>> +
>>> +&cooling_map6 {
>>> + cooling-device = <&cpu4 3 11>;
>>> +};
>>> +
>>> &pwm {
>>> /*
>>> * PWM 0 -- fan
>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>> @@ -146,6 +146,10 @@
>>> vdd-supply = <&ldo9_reg>;
>>> };
>>>
>>> +&cluster_a7_opp_table {
>>> + /delete-property/opp at 1400000000;
>>> +};
>>> +
>>> &cpu0 {
>>> cpu-supply = <&buck2_reg>;
>>> };
>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>> ===================================================================
>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>> @@ -24,6 +24,16 @@
>>> };
>>>
>>> &cluster_a15_opp_table {
>>> + opp at 2000000000 {
>>> + opp-hz = /bits/ 64 <2000000000>;
>>> + opp-microvolt = <1250000>;
>>> + clock-latency-ns = <140000>;
>>> + };
>>> + opp at 1900000000 {
>>> + opp-hz = /bits/ 64 <1900000000>;
>>> + opp-microvolt = <1250000>;
>>> + clock-latency-ns = <140000>;
>>> + };
>>> opp at 1700000000 {
>>> opp-microvolt = <1250000>;
>>> };
>>> @@ -85,6 +95,11 @@
>>> };
>>>
>>
>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>> INT rail would need to be scaled up as well since there's a maximum voltage
>> difference between the ARM and INT rails before the system becomes unstable:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>> https://lkml.org/lkml/2014/5/2/419
>>
>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>> the maximum voltage skew is between a limit. But that never made to mainline:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>> https://lkml.org/lkml/2014/4/29/28
>>
>> Did that change and there's infrastructure in mainline now to cope with that?
>> If that's the case, I think it would be good to mention in the commit message.
>
> I was not aware of this limitation and AFAIK mainline has currently
> no code to handle it. I also cannot find any code to handle this in
Yes, that's what I thought as well but maybe I was missing something.
> Hardkernel's vendor kernel for Odroid-XU3 board.
>
> Do you know whether this problem exists also on Exynos5422/5800
> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> regulator code also on Exynos5800 SoC based Peach Pi board but was
> the problem actually present on this board?
>
My understanding is that this problem is present in 5420/5422/5800
but I have no way to confirm this. I'm just guessing from the info
in the ChromiumOS vendor tree.
If you look at the commit that added the regulator-locker driver,
the test says to be done in a Peach Pi so it seems the problem is
not restricted to only Exynos5420:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> (unfortunately Inderpal's email is no longer working). ]
>
Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> IOW if the problem exists it is already present in the mainline
> kernel.
>
Ah, I only looked at your patch and I didn't compare the voltage levels
in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
I wonder if the voltage levels in your patch are correct then, since the
ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
/*
* Default ASV table
*/
static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
1362500, /* L0 2100 */
1312500, /* L1 2000 */
1275000, /* L2 1900 */
1225000, /* L3 1800 */
1200000, /* L4 1700 */
This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Maxime Ripard @ 2016-12-14 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214100856.23735-1-manu@bidouilliste.com>
Hi Emmanuel,
On Wed, Dec 14, 2016 at 11:08:56AM +0100, Emmanuel Vadot wrote:
> The node name for the power seq pin is mmc2 at 0 like the mmc2_pins_a one.
> This makes the original node (mmc2_pins_a) scrapped out of the dtb and
> result in a unusable eMMC if U-Boot didn't configured the pins to the
> correct functions.
>
> Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> ---
> arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> index 5ea4915..68cb1b5 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> @@ -56,7 +56,7 @@
> };
>
> &pio {
> - mmc2_pins_nrst: mmc2 at 0 {
> + mmc2_pins_nrst: mmc2 at 1 {
That would be even better if you renamed it to something like
mmc2-rst-pin to avoid all future conflicts (for example if we ever add
a second mmc pins groups.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/a7d1b197/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
From: Pratyush Anand @ 2016-12-14 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214134457.GJ17982@leverpostej>
On Wednesday 14 December 2016 07:14 PM, Mark Rutland wrote:
>> Even for the non-kdump ie `kexec -l` case we do not have a
>> > functionality to bypass sha verification in kexec-tools. --lite
>> > option with the kexec-tools was discouraged and not accepted.
> Ok. Do you have a pointer to the thread regarding that, for context?
>
https://lists.ozlabs.org/pipermail/petitboot/2015-October/000141.html
https://lists.ozlabs.org/pipermail/petitboot/2015-October/000136.html
~Pratyush
^ permalink raw reply
* [PATCH linux v1 0/4] Seven segment display support
From: Arnd Bergmann @ 2016-12-14 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ac324946-41da-c090-a0ca-78155611bb7e@baylibre.com>
On Wednesday, December 14, 2016 2:12:41 PM CET Neil Armstrong wrote:
> On 12/14/2016 01:56 PM, Greg KH wrote:
> > On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
> >> Hello,
> >>
> >> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
> >> Natarajan wrote:
> >>
> >>> Documentation for the binding which provides an interface for adding clock,
> >>> data and clear signal GPIO lines to control seven segment display.
> >>>
> >>> The platform device driver provides an API for displaying on two 7-segment
> >>> displays, and implements the required bit-banging. The hardware assumed is
> >>> 74HC164 wired to two 7-segment displays.
> >>>
> >>> The character device driver implements the user-space API for letting a user
> >>> write to two 7-segment displays including any conversion methods necessary
> >>> to map the user input to two 7-segment displays.
> >>>
> >>> Adding clock, data and clear signal GPIO lines in the devicetree to control
> >>> seven segment display on zaius platform.
> >>>
> >>> The platform driver matches on the device tree node; the platform driver also
> >>> initializes the character device.
> >>>
> >>> Tested that the seven segment display works properly by writing to the
> >>> character device file on a EVB AST2500 board which also has 74HC164 wired
> >>> to two 7-segment displays.
> >>
> >> FWIW, I proposed a driver for seven segment displays back in 2013:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
> >>
> >> And the feedback from Greg KH was: we don't need a driver for that, do
> >> it from userspace. See:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
> >>
> >> So: good luck
> >
> > Did anyone ever write a library for this type of thing?
> >
> > Again, I don't want to see one-off drivers for random devices like this
> > that should be able to all be controlled from userspace in a common
> > manner. Much like we did for fingerprint readers a long long time
> > ago...
> >
> Actually, it's more than a random interface, a lot of SoCs and boards actually have such displays
> and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly stuff to only print a few
> characters a simple and clean driver could achieve.
> Some very well known SoCs even have integrated registers to lower the BOM and bypass the need for
> a 74HC164 like component and avoid gpio bit banging.
>
> My personal concern is that you could also need to drive more segments, thus 7-segments
> is too restrictive.
>
> But this driver is well structured, the gpio-bitbanging sub-driver is welcome.
Maybe we can find a way to fit this into the existing drivers/leds/ subsystem?
That already supports blinking, brightness and colour attributes of LEDs,
so could this be extended to support (one of) digit, number, character
or string with a common sysfs attribute and a way to hook up a led driver
to that?
Arnd
^ permalink raw reply
* [RESEND PATCH 0/2] fix some trivial bug involving the contiguous bit
From: zhongjiang @ 2016-12-14 14:19 UTC (permalink / raw)
To: linux-arm-kernel
From: zhong jiang <zhongjiang@huawei.com>
Hi,
The following patch have sent it last week, but it fails to receive any reply.
These patch is simple but reasonable. I hope it can merge to next version. So,
if anyone has any objection, just please let me know.
Thanks
zhongjiang
zhong jiang (2):
arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT
arm64: make WANT_HUGE_PMD_SHARE depends on HUGETLB_PAGE
arch/arm64/Kconfig | 1 +
arch/arm64/mm/hugetlbpage.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--
1.8.3.1
^ permalink raw reply
* [RESEND PATCH 1/2] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT
From: zhongjiang @ 2016-12-14 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481725151-20549-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
I think that CONT_PTE_SHIFT is more reasonable even if they are some
value. and the patch is not any functional change.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
arch/arm64/mm/hugetlbpage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 2e49bd2..0a4c97b 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -323,7 +323,7 @@ static __init int setup_hugepagesz(char *opt)
static __init int add_default_hugepagesz(void)
{
if (size_to_hstate(CONT_PTES * PAGE_SIZE) == NULL)
- hugetlb_add_hstate(CONT_PMD_SHIFT);
+ hugetlb_add_hstate(CONT_PTE_SHIFT);
return 0;
}
arch_initcall(add_default_hugepagesz);
--
1.8.3.1
^ permalink raw reply related
* [RESEND PATCH 2/2] arm64: make WANT_HUGE_PMD_SHARE depends on HUGETLB_PAGE
From: zhongjiang @ 2016-12-14 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481725151-20549-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
when HUGETLB_PAGE is disable, WANT_HUGE_PMD_SHARE contains the
fuctions should not be use. therefore, we add the dependency.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 969ef88..694ca73 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -640,6 +640,7 @@ config SYS_SUPPORTS_HUGETLBFS
config ARCH_WANT_HUGE_PMD_SHARE
def_bool y if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
+ depends on HUGETLB_PAGE
config ARCH_HAS_CACHE_LINE_SIZE
def_bool y
--
1.8.3.1
^ permalink raw reply related
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