Re: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function fm10k_probe
On 10/16/2015 12:42 PM, Nicholas Krause wrote: This fixes error handling in the function fm10k_probe to properly if the call to the function fm10k_iov_configure has failed by returning a error code before jumping to a new goto label, fm10k_iov_configure to clean up previously allocated resources between this goto label and the previous goto label before finally returning the error code to the callers of the function fm10k_probe Signed-off-by: Nicholas Krause --- drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c index ce53ff2..3d7374e 100644 --- a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c +++ b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c @@ -1844,13 +1844,17 @@ static int fm10k_probe(struct pci_dev *pdev, fm10k_slot_warn(interface); /* enable SR-IOV after registering netdev to enforce PF/VF ordering */ - fm10k_iov_configure(pdev, 0); + err = fm10k_iov_configure(pdev, 0); + if (err) + goto err_iov_configure; /* clear the service task disable bit to allow service task to start */ clear_bit(__FM10K_SERVICE_DISABLE, &interface->state); return 0; - +err_iov_configure: + fm10k_ptp_unregister(interface); + unregister_netdev(netdev); err_register: fm10k_mbx_free_irq(interface); err_mbx_interrupt: Failing to enable SR-IOV is not grounds for not brining up the interface. The NIC is still usable, it just cannot do SR-IOV. The only reason fm10k_iov_configure has a return value is because it is also passed through the PCI interface to allow the sysfs control. If it returns an error there then it is much more important as the user actually requested it be enabled. If you would like you could display a message there but this shouldn't be a hard error. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.2 41/54] drm/nouveau/fbcon: take runpm reference when userspace has an open fd
On Fri, 2015-10-23 at 10:45 -0700, Greg Kroah-Hartman wrote:
> 4.2-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Ben Skeggs
>
> commit f231976c2e8964ceaa9250e57d27c35ff03825c2 upstream.
>
> We need to do this in order to prevent accesses to the device while it's
> powered down. Userspace may have an mmap of the fb, and there's no good
> way (that I know of) to prevent it from touching the device otherwise.
>
> This fixes some nasty races between runpm and plymouth on some systems,
> which result in the GPU getting very upset and hanging the boot.
>
> Signed-off-by: Ben Skeggs
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 24
> 1 file changed, 24 insertions(+)
>
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -178,8 +178,30 @@ nouveau_fbcon_sync(struct fb_info *info)
> >> return 0;
> }
>
> +static int
> +nouveau_fbcon_open(struct fb_info *info, int user)
> +{
> +>> struct nouveau_fbdev *fbcon = info->par;
> +>> struct nouveau_drm *drm = nouveau_drm(fbcon->dev);
> +>> int ret = pm_runtime_get_sync(drm->dev->dev);
> + if (ret < 0 && ret != -EACCES)
> + return ret;
> +>> return 0;
> +}
[...]
As pm_runtime_get_sync() always bumps the usage count, the error path
here should call pm_runtime_put().
Ben.
>
--
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth
signature.asc
Description: This is a digitally signed message part
Re: [PATCH RFC net-next 0/2] tcp: Redundant Data Bundling (RDB)
On Fri, Oct 23, 2015 at 1:50 PM, Bendik Rønning Opstad wrote: > > This is a request for comments. > > Redundant Data Bundling (RDB) is a mechanism for TCP aimed at reducing > the latency for applications sending time-dependent data. > Latency-sensitive applications or services, such as online games and > remote desktop, produce traffic with thin-stream characteristics, > characterized by small packets and a relatively high ITT. By bundling > already sent data in packets with new data, RDB alleviates head-of-line > blocking by reducing the need to retransmit data segments when packets > are lost. RDB is a continuation on the work on latency improvements for > TCP in Linux, previously resulting in two thin-stream mechanisms in the > Linux kernel > (https://github.com/torvalds/linux/blob/master/Documentation/networking/tcp-thin.txt). > > The RDB implementation has been thoroughly tested, and shows > significant latency reductions when packet loss occurs[1]. The tests > show that, by imposing restrictions on the bundling rate, it can be made > not to negatively affect competing traffic in an unfair manner. > > Note: Current patch set depends on a recently submitted patch for > tcp_skb_cb (tcp: refactor struct tcp_skb_cb: > http://patchwork.ozlabs.org/patch/510674) > > These patches have been tested with as set of packetdrill scripts located at > https://github.com/bendikro/packetdrill/tree/master/gtests/net/packetdrill/tests/linux/rdb > (The tests require patching packetdrill with a new socket option: > https://github.com/bendikro/packetdrill/commit/9916b6c53e33dd04329d29b7d8baf703b2c2ac1b) > > Detailed info about the RDB mechanism can be found at > http://mlab.no/blog/2015/10/redundant-data-bundling-in-tcp, as well as in the > paper What's the difference between RDB and TCP repacketization (http://flylib.com/books/en/3.223.1.226/1/) ? Reading the blog page, I am concerned the amount of change (esp on fast path) just to bundle new writes during timeout & retransmit, for a specific type of application? why not just send X packets with total bytes < MSS on timeout.. > "Latency and Fairness Trade-Off for Thin Streams using Redundant Data > Bundling in TCP"[2]. > > [1] http://home.ifi.uio.no/paalh/students/BendikOpstad.pdf > [2] http://home.ifi.uio.no/bendiko/rdb_fairness_tradeoff.pdf > > > Bendik Rønning Opstad (2): > tcp: Add DPIFL thin stream detection mechanism > tcp: Add Redundant Data Bundling (RDB) > > Documentation/networking/ip-sysctl.txt | 23 +++ > include/linux/skbuff.h | 1 + > include/linux/tcp.h| 9 +- > include/net/tcp.h | 34 > include/uapi/linux/tcp.h | 1 + > net/core/skbuff.c | 3 +- > net/ipv4/Makefile | 3 +- > net/ipv4/sysctl_net_ipv4.c | 35 > net/ipv4/tcp.c | 19 ++- > net/ipv4/tcp_input.c | 3 + > net/ipv4/tcp_output.c | 11 +- > net/ipv4/tcp_rdb.c | 281 > + > 12 files changed, 415 insertions(+), 8 deletions(-) > create mode 100644 net/ipv4/tcp_rdb.c > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-wired-lan] [PATCH] e1000e:Fix incorrect assumption that the function e1000e_up always runs successfully in e1000_change_mtu
On 10/23/2015 09:09 PM, Nicholas Krause wrote:
This fixes the function e1000_change_mtu to properly check and run
the error code by e1000e_up as this function can fail and the error
code should be returned to the caller of the function e1000_change_mtu
to signal a error has occurred when calling this particular function
The function e1000e_up always returns 0. It should probably be switched
to a void instead of an int. You could probably go through and drop a
bunch of dead code that is checking for the result of that function as well.
Signed-off-by: Nicholas Krause
---
drivers/net/ethernet/intel/e1000e/netdev.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index faf4b3f..aebccb1 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5931,6 +5931,7 @@ static int e1000_change_mtu(struct net_device *netdev,
int new_mtu)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
int max_frame = new_mtu + VLAN_ETH_HLEN + ETH_FCS_LEN;
+ int err = 0;
/* Jumbo frame support */
if ((max_frame > (VLAN_ETH_FRAME_LEN + ETH_FCS_LEN)) &&
@@ -5984,7 +5985,9 @@ static int e1000_change_mtu(struct net_device *netdev,
int new_mtu)
adapter->rx_buffer_len = VLAN_ETH_FRAME_LEN + ETH_FCS_LEN;
if (netif_running(netdev))
- e1000e_up(adapter);
+ err = e1000e_up(adapter);
+ if (err)
+ e_err("Failed to successfully bring up this adapter\n");
else
e1000e_reset(adapter);
@@ -5992,7 +5995,7 @@ static int e1000_change_mtu(struct net_device *netdev, int new_mtu)
clear_bit(__E1000_RESETTING, &adapter->state);
- return 0;
+ return err;
}
static int e1000_mii_ioctl(struct net_device *netdev, struct ifreq *ifr,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH net-next] net/core: initial support for stacked dev feature toggles
On 10/23/2015 08:40 PM, Jarod Wilson wrote:
There are some netdev features that make little sense to toggle on and
off in a stacked device setup on only one device in the stack. The prime
example is a bonded connection, where it really doesn't make sense to
disable LRO on the master, but not on any of the slaves, nor does it
really make sense to be able to shut LRO off on a slave when its still
enabled on the master.
The strategy here is to add a section near the end of
netdev_fix_features() that looks for upper and lower netdevs, then make
sure certain feature flags match both up and down the stack. At present,
only the LRO flag is included.
This has been successfully tested with bnx2x, qlcnic and netxen network
cards as slaves in a bond interface. Turning LRO on or off on the master
also turns it on or off on each of the slaves, new slaves are added with
LRO in the same state as the master, and LRO can't be toggled on the
slaves.
Also, this should largely remove the need for dev_disable_lro(), and most,
if not all, of its call sites can be replaced by simply making sure
NETIF_F_LRO isn't included in the relevant device's feature flags.
Note that this patch is driven by bug reports from users saying it was
confusing that bonds and slaves had different settings for the same
features, and while it won't be 100% in sync if a lower device doesn't
support a feature like LRO, I think this is a good step in the right
direction.
CC: "David S. Miller"
CC: Eric Dumazet
CC: Jay Vosburgh
CC: Veaceslav Falico
CC: Andy Gospodarek
CC: Jiri Pirko
CC: Nikolay Aleksandrov
CC: Michal Kubecek
CC: net...@vger.kernel.org
Signed-off-by: Jarod Wilson
---
net/core/dev.c | 57 +
1 file changed, 57 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 1225b4b..26f4e2d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6261,9 +6261,57 @@ static void rollback_registered(struct net_device *dev)
list_del(&single);
}
+static netdev_features_t netdev_sync_upper_features(struct net_device *lower,
+ struct net_device *upper, netdev_features_t features)
+{
+ netdev_features_t want = upper->wanted_features & lower->hw_features;
+
+ if (!(upper->wanted_features & NETIF_F_LRO)
+ && (features & NETIF_F_LRO)) {
+ netdev_info(lower, "Dropping LRO, upper dev %s has it off.\n",
+ upper->name);
+ features &= ~NETIF_F_LRO;
+ } else if ((want & NETIF_F_LRO) && !(features & NETIF_F_LRO)) {
+ netdev_info(lower, "Keeping LRO, upper dev %s has it on.\n",
+ upper->name);
+ features |= NETIF_F_LRO;
+ }
+
+ return features;
+}
+
I'd say to drop the second half of this statement. LRO is a feature
that should be enabled explicitly per interface. If someone enables LRO
on the master they may only want it on one interface. The fact is there
are some implementations of LRO that work better than others so you want
to give the end user the option to mix and match.
+static void netdev_sync_lower_features(struct net_device *upper,
+ struct net_device *lower, netdev_features_t features)
+{
+ netdev_features_t want = features & lower->hw_features;
+
+ if (!(features & NETIF_F_LRO) && (lower->features & NETIF_F_LRO)) {
+ netdev_info(upper, "Disabling LRO on lower dev %s.\n",
+ lower->name);
+ upper->wanted_features &= ~NETIF_F_LRO;
+ lower->wanted_features &= ~NETIF_F_LRO;
+ netdev_update_features(lower);
+ if (unlikely(lower->features & NETIF_F_LRO))
+ netdev_WARN(upper, "failed to disable LRO on %s!\n",
+ lower->name);
+ } else if ((want & NETIF_F_LRO) && !(lower->features & NETIF_F_LRO)) {
+ netdev_info(upper, "Enabling LRO on lower dev %s.\n",
+ lower->name);
+ upper->wanted_features |= NETIF_F_LRO;
+ lower->wanted_features |= NETIF_F_LRO;
+ netdev_update_features(lower);
+ if (unlikely(!(lower->features & NETIF_F_LRO)))
+ netdev_WARN(upper, "failed to enable LRO on %s!\n",
+ lower->name);
+ }
+}
+
Same thing here. If a lower dev has it disabled then leave it disabled.
I believe your goal is to make it so that dev_disable_lro() can shut
down LRO when it is making packets in the data-path unusable. There is
no need to make this an all or nothing scenario. We can let the stack
slam things down with dev_disable_lro() and then if a user so desires
they can come back through and enable LRO more selectively if they for
instance have an interface that can do a smarter job of putting together
frames that could be routed.
You could probably look at doing something like this f
Re: [PATCH 4.2 25/54] memcg: convert threshold to bytes
On Fri, 2015-10-23 at 10:45 -0700, Greg Kroah-Hartman wrote:
> 4.2-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Shaohua Li
>
> commit 424cdc14138088ada1b0e407a2195b2783c6e5ef upstream.
>
> page_counter_memparse() returns pages for the threshold, while
> mem_cgroup_usage() returns bytes for memory usage. Convert the
> threshold to bytes.
>
> Fixes: 3e32cb2e0a12b6915 ("memcg: rename cgroup_event to mem_cgroup_event").
> Signed-off-by: Shaohua Li
> Cc: Johannes Weiner
> Acked-by: Michal Hocko
> Signed-off-by: Andrew Morton
> Signed-off-by: Linus Torvalds
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> mm/memcontrol.c |1 +
> 1 file changed, 1 insertion(+)
>
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3687,6 +3687,7 @@ static int __mem_cgroup_usage_register_e
> >> ret = page_counter_memparse(args, "-1", &threshold);
> >> if (ret)
> >> > return ret;
> +>> threshold <<= PAGE_SHIFT;
>
> >> mutex_lock(&memcg->thresholds_lock);
>
mem_cgroup_usage() returns a u64 and I think that the types of
threshold and mem_cgroup_threshold::threshold also need be changed to
u64 to avoid overflow on large 32-bit systems.
Ben.
--
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler
On 10/22/2015 09:04 PM, Doug Anderson wrote:
Krzysztof,
On Wed, Oct 21, 2015 at 6:43 PM, Krzysztof Kozlowski
wrote:
I think at least one platform may be affected because it used
mmc-pwrseq-emmc and gpio-restart.
Look at rk3288-veyron.dtsi.
Both of restart handlers had the priority of 129 which means that the
order of execution depends on probing sequence. Now you will make the
sequence strict - first mmc then gpio.
You seems convinced that this is not a problem... I don't know. I would
prefer test this on affected platforms before risking to break them.
It's annoying if fix for one SoC breaks another.
Assuming I'm understanding things properly, veyron isn't using 129 as
a priority. In the dts file:
gpio-restart {
compatible = "gpio-restart";
gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&ap_warm_reset_h>;
priority = <200>;
};
...so it overrides the default 129 with 200. Ah, but Javier already
pointed that out in his reply.
Since the current mmc_pwrseq_emmc_reset_nb notifier priority is 129,
eMMC reset will not work if one of the platforms you mentioned needs
this since the system restart handler with prio 192 will be executed
before the eMMC one, leaving the eMMC in an unknown state on reboot.
And now you will "fix this" by making eMMC working correctly. So let's
make it straight:
1. Previously the eMMC could be left on these platforms in an unknown
state (because emmc handler was not executed).
2. No one complained! Which could mean that in fact this was working fine...
3. Now you will change it.
4. Maybe someone will complain?
On veyron boards the reset shouldn't hurt. The eMMC reset will
actually get asserted at reset anyway since the reset will reset GPIO
states and the default GPIO state for the eMMC line asserts reset.
OK, I just picked this onto Heiko's somewhat "stable-tree"
(v4.3-rc3-876-g6509232) from
Re: [RFC PATCH net-next] net/core: initial support for stacked dev feature toggles
On Fri, Oct 23, 2015 at 11:40 PM, Jarod Wilson wrote:
> There are some netdev features that make little sense to toggle on and
> off in a stacked device setup on only one device in the stack. The prime
> example is a bonded connection, where it really doesn't make sense to
> disable LRO on the master, but not on any of the slaves, nor does it
> really make sense to be able to shut LRO off on a slave when its still
> enabled on the master.
>
> The strategy here is to add a section near the end of
> netdev_fix_features() that looks for upper and lower netdevs, then make
> sure certain feature flags match both up and down the stack. At present,
> only the LRO flag is included.
>
> This has been successfully tested with bnx2x, qlcnic and netxen network
> cards as slaves in a bond interface. Turning LRO on or off on the master
> also turns it on or off on each of the slaves, new slaves are added with
> LRO in the same state as the master, and LRO can't be toggled on the
> slaves.
>
> Also, this should largely remove the need for dev_disable_lro(), and most,
> if not all, of its call sites can be replaced by simply making sure
> NETIF_F_LRO isn't included in the relevant device's feature flags.
>
> Note that this patch is driven by bug reports from users saying it was
> confusing that bonds and slaves had different settings for the same
> features, and while it won't be 100% in sync if a lower device doesn't
> support a feature like LRO, I think this is a good step in the right
> direction.
>
I don't see what real problem this is solving. LRO is purely a feature
of physical devices and should be irrelevant to be configured on any
type of virtual device. I think the same thing will be true of RX csum
and other device RX functions (but this is not true for transmit
features). Seems like a better fix might be to disallow setting these
features on the bonding device in the first place, then we don't need
to worry about syncing them amongst slaves-- if a user needs that it's
a simple script.
Tom
> CC: "David S. Miller"
> CC: Eric Dumazet
> CC: Jay Vosburgh
> CC: Veaceslav Falico
> CC: Andy Gospodarek
> CC: Jiri Pirko
> CC: Nikolay Aleksandrov
> CC: Michal Kubecek
> CC: net...@vger.kernel.org
> Signed-off-by: Jarod Wilson
> ---
> net/core/dev.c | 57 +
> 1 file changed, 57 insertions(+)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 1225b4b..26f4e2d 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6261,9 +6261,57 @@ static void rollback_registered(struct net_device *dev)
> list_del(&single);
> }
>
> +static netdev_features_t netdev_sync_upper_features(struct net_device *lower,
> + struct net_device *upper, netdev_features_t features)
> +{
> + netdev_features_t want = upper->wanted_features & lower->hw_features;
> +
> + if (!(upper->wanted_features & NETIF_F_LRO)
> + && (features & NETIF_F_LRO)) {
> + netdev_info(lower, "Dropping LRO, upper dev %s has it off.\n",
> + upper->name);
> + features &= ~NETIF_F_LRO;
> + } else if ((want & NETIF_F_LRO) && !(features & NETIF_F_LRO)) {
> + netdev_info(lower, "Keeping LRO, upper dev %s has it on.\n",
> + upper->name);
> + features |= NETIF_F_LRO;
> + }
> +
> + return features;
> +}
> +
> +static void netdev_sync_lower_features(struct net_device *upper,
> + struct net_device *lower, netdev_features_t features)
> +{
> + netdev_features_t want = features & lower->hw_features;
> +
> + if (!(features & NETIF_F_LRO) && (lower->features & NETIF_F_LRO)) {
> + netdev_info(upper, "Disabling LRO on lower dev %s.\n",
> + lower->name);
> + upper->wanted_features &= ~NETIF_F_LRO;
> + lower->wanted_features &= ~NETIF_F_LRO;
> + netdev_update_features(lower);
> + if (unlikely(lower->features & NETIF_F_LRO))
> + netdev_WARN(upper, "failed to disable LRO on %s!\n",
> + lower->name);
> + } else if ((want & NETIF_F_LRO) && !(lower->features & NETIF_F_LRO)) {
> + netdev_info(upper, "Enabling LRO on lower dev %s.\n",
> + lower->name);
> + upper->wanted_features |= NETIF_F_LRO;
> + lower->wanted_features |= NETIF_F_LRO;
> + netdev_update_features(lower);
> + if (unlikely(!(lower->features & NETIF_F_LRO)))
> + netdev_WARN(upper, "failed to enable LRO on %s!\n",
> + lower->name);
> + }
> +}
> +
> static netdev_features_t netdev_fix_features(struct net_device *dev,
> netdev_features_t features)
> {
> + struct net_device *upper, *lower;
> + struct list_head *iter;
> +
> /* Fix illegal checksum combination
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy
On Sat, 2015-10-24 at 07:21 +0900, Tejun Heo wrote: > It'd be a step back in usability only for users who have been using > cgroups in fringing ways which can't be justified for ratification and > we do want to actively filter those out. Of all the cgroup signal currently in existence, seems the Google signal has to have the most volume under the curve by a mile. If you were to filter that signal out, what remained would be a flat line of noise. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] serial: 8250_early: do not save and restore IER in write callback
The IER has already been masked in early_serial8250_setup(), there is
no reason to save and restore it every time early_serial8250_write()
is called.
Signed-off-by: Masahiro Yamada
---
drivers/tty/serial/8250/8250_early.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_early.c
b/drivers/tty/serial/8250/8250_early.c
index 7aff3d8..559b681 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -99,20 +99,8 @@ static void __init early_serial8250_write(struct console
*console,
{
struct earlycon_device *device = console->data;
struct uart_port *port = &device->port;
- unsigned int ier;
-
- /* Save the IER and disable interrupts preserving the UUE bit */
- ier = serial8250_early_in(port, UART_IER);
- if (ier)
- serial8250_early_out(port, UART_IER, ier & UART_IER_UUE);
uart_console_write(port, s, count, serial_putc);
-
- /* Wait for transmitter to become empty and restore the IER */
- wait_for_xmitr(port);
-
- if (ier)
- serial8250_early_out(port, UART_IER, ier);
}
static void __init init_port(struct earlycon_device *device)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] serial: 8250_early: squash wait_for_xmitr() into serial_putc()
Now, wait_for_xmitr() is only called from serial_putc(), and both
are short enough. They can be merged into a single function.
Signed-off-by: Masahiro Yamada
---
drivers/tty/serial/8250/8250_early.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_early.c
b/drivers/tty/serial/8250/8250_early.c
index 559b681..19aca19 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -76,21 +76,17 @@ static void __init serial8250_early_out(struct uart_port
*port, int offset, int
#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
-static void __init wait_for_xmitr(struct uart_port *port)
+static void __init serial_putc(struct uart_port *port, int c)
{
unsigned int status;
for (;;) {
status = serial8250_early_in(port, UART_LSR);
if ((status & BOTH_EMPTY) == BOTH_EMPTY)
- return;
+ break;
cpu_relax();
}
-}
-static void __init serial_putc(struct uart_port *port, int c)
-{
- wait_for_xmitr(port);
serial8250_early_out(port, UART_TX, c);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] serial: 8250_early: simplify serial_putc()
Changes in v2: - split into two patches Masahiro Yamada (2): serial: 8250_early: do not save and restore IER in write callback serial: 8250_early: squash wait_for_xmitr() into serial_putc() drivers/tty/serial/8250/8250_early.c | 20 ++-- 1 file changed, 2 insertions(+), 18 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4] hp_sdc: convert struct timeval to ktime_t
struct timeval is not y2038 safe, convert it to ktime_t,
and there is no need to handle sec and usec separately
And since hp_sdc.rtv is only used for time diff, monotonic time
is better here
Signed-off-by: WEN Pingbo
---
Version 2:
Using ktime_t instead of struct timespec64
Version 3:
Commit msg adjustment, and using ktime_to_ns to extract nsecs
Version 4:
Correct commit msg format
drivers/input/serio/hp_sdc.c | 16 ++--
include/linux/hp_sdc.h | 6 +++---
2 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/input/serio/hp_sdc.c b/drivers/input/serio/hp_sdc.c
index 852858e..17e3725 100644
--- a/drivers/input/serio/hp_sdc.c
+++ b/drivers/input/serio/hp_sdc.c
@@ -193,7 +193,7 @@ static void hp_sdc_take(int irq, void *dev_id, uint8_t
status, uint8_t data)
curr->seq[curr->idx++] = status;
curr->seq[curr->idx++] = data;
hp_sdc.rqty -= 2;
- do_gettimeofday(&hp_sdc.rtv);
+ hp_sdc.rtv = ktime_get();
if (hp_sdc.rqty <= 0) {
/* All data has been gathered. */
@@ -306,13 +306,9 @@ static void hp_sdc_tasklet(unsigned long foo)
write_lock_irq(&hp_sdc.rtq_lock);
if (hp_sdc.rcurr >= 0) {
- struct timeval tv;
+ ktime_t time_diff = ktime_sub(ktime_get(), hp_sdc.rtv);
- do_gettimeofday(&tv);
- if (tv.tv_sec > hp_sdc.rtv.tv_sec)
- tv.tv_usec += USEC_PER_SEC;
-
- if (tv.tv_usec - hp_sdc.rtv.tv_usec > HP_SDC_MAX_REG_DELAY) {
+ if (ktime_to_ns(time_diff) > HP_SDC_MAX_REG_DELAY) {
hp_sdc_transaction *curr;
uint8_t tmp;
@@ -321,8 +317,8 @@ static void hp_sdc_tasklet(unsigned long foo)
* we'll need to figure out a way to communicate
* it back to the application. and be less verbose.
*/
- printk(KERN_WARNING PREFIX "read timeout (%ius)!\n",
- (int)(tv.tv_usec - hp_sdc.rtv.tv_usec));
+ printk(KERN_WARNING PREFIX "read timeout (%llins)!\n",
+ ktime_to_ns(time_diff));
curr->idx += hp_sdc.rqty;
hp_sdc.rqty = 0;
tmp = curr->seq[curr->actidx];
@@ -551,7 +547,7 @@ unsigned long hp_sdc_put(void)
/* Start a new read */
hp_sdc.rqty = curr->seq[curr->idx];
- do_gettimeofday(&hp_sdc.rtv);
+ hp_sdc.rtv = ktime_get();
curr->idx++;
/* Still need to lock here in case of spurious irq. */
write_lock_irq(&hp_sdc.rtq_lock);
diff --git a/include/linux/hp_sdc.h b/include/linux/hp_sdc.h
index d392975..348a9b5 100644
--- a/include/linux/hp_sdc.h
+++ b/include/linux/hp_sdc.h
@@ -47,9 +47,9 @@
#endif
-/* No 4X status reads take longer than this (in usec).
+/* No 4X status reads take longer than this (in nsec).
*/
-#define HP_SDC_MAX_REG_DELAY 2
+#define HP_SDC_MAX_REG_DELAY 2000
typedef void (hp_sdc_irqhook) (int irq, void *dev_id,
uint8_t status, uint8_t data);
@@ -281,7 +281,7 @@ typedef struct {
hp_sdc_transaction *tq[HP_SDC_QUEUE_LEN]; /* All pending read/writes */
int rcurr, rqty;/* Current read transact in process */
- struct timeval rtv;/* Time when current read started */
+ ktime_t rtv;/* Time when current read started */
int wcurr; /* Current write transact in process */
int dev_err;/* carries status from registration */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: 8250_early: do not save and restore IER in write callback
Hi Peter, 2015-10-23 21:45 GMT+09:00 Peter Hurley : > On 10/22/2015 04:21 AM, Masahiro Yamada wrote: >> The IER has already been masked in early_serial8250_setup(), there is >> no reason to save and restore it every time early_serial8250_write() >> is called. >> >> Let wait_for_xmitr() melt into serial_putc(). > > Both of these changes are ok with me, but please split this into > 2 patches so reverting either one in case of regression is trivial. > > Regards, > Peter Hurley OK, will do. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 2/2] hil_mlc: convert timeval to jiffies
struct timeval is not y2038 safe, and what mlc->instart do is
scheduling a task in a fixed timeout, so jiffies is the
simplest choice here.
In hilse_donode(), the expires in mod_timer equals
jiffies + intimeout - (now - instart)
If we use jiffies in 'now', the expires equals
instart + intimeout
So, all we need to do is that making sure expires is a future
timestamp before passed it to mod_timer
Signed-off-by: WEN Pingbo
---
Version 2:
Using ktime_t to fix y2038 problem
Version 3:
Convert it to jiffies
drivers/input/serio/hil_mlc.c| 17 +++--
drivers/input/serio/hp_sdc_mlc.c | 7 +++
include/linux/hil_mlc.h | 2 +-
3 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/input/serio/hil_mlc.c b/drivers/input/serio/hil_mlc.c
index fb297aa..5428098 100644
--- a/drivers/input/serio/hil_mlc.c
+++ b/drivers/input/serio/hil_mlc.c
@@ -603,7 +603,7 @@ static inline void hilse_setup_input(hil_mlc *mlc, const
struct hilse_node *node
}
mlc->istarted = 1;
mlc->intimeout = node->arg;
- do_gettimeofday(&(mlc->instart));
+ mlc->instart = jiffies;
mlc->icount = 15;
memset(mlc->ipacket, 0, 16 * sizeof(hil_packet));
BUG_ON(down_trylock(&mlc->isem));
@@ -708,7 +708,7 @@ static int hilse_donode(hil_mlc *mlc)
break;
}
mlc->ostarted = 0;
- do_gettimeofday(&(mlc->instart));
+ mlc->instart = jiffies;
write_unlock_irqrestore(&mlc->lock, flags);
nextidx = HILSEN_NEXT;
break;
@@ -729,18 +729,15 @@ static int hilse_donode(hil_mlc *mlc)
#endif
while (nextidx & HILSEN_SCHED) {
- struct timeval tv;
+ unsigned long expires = mlc->instart +
+ usecs_to_jiffies(mlc->intimeout);
if (!sched_long)
goto sched;
- do_gettimeofday(&tv);
- tv.tv_usec += USEC_PER_SEC * (tv.tv_sec - mlc->instart.tv_sec);
- tv.tv_usec -= mlc->instart.tv_usec;
- if (tv.tv_usec >= mlc->intimeout) goto sched;
- tv.tv_usec = (mlc->intimeout - tv.tv_usec) * HZ / USEC_PER_SEC;
- if (!tv.tv_usec) goto sched;
- mod_timer(&hil_mlcs_kicker, jiffies + tv.tv_usec);
+ if (time_after_eq(jiffies, expires))
+ goto sched;
+ mod_timer(&hil_mlcs_kicker, expires);
break;
sched:
tasklet_schedule(&hil_mlcs_tasklet);
diff --git a/drivers/input/serio/hp_sdc_mlc.c b/drivers/input/serio/hp_sdc_mlc.c
index d50f067..b91d5bb 100644
--- a/drivers/input/serio/hp_sdc_mlc.c
+++ b/drivers/input/serio/hp_sdc_mlc.c
@@ -149,7 +149,6 @@ static int hp_sdc_mlc_in(hil_mlc *mlc, suseconds_t timeout)
/* Try to down the semaphore */
if (down_trylock(&mlc->isem)) {
- struct timeval tv;
if (priv->emtestmode) {
mlc->ipacket[0] =
HIL_ERR_INT | (mlc->opacket &
@@ -160,9 +159,9 @@ static int hp_sdc_mlc_in(hil_mlc *mlc, suseconds_t timeout)
/* printk(KERN_DEBUG PREFIX ">[%x]\n",
mlc->ipacket[0]); */
goto wasup;
}
- do_gettimeofday(&tv);
- tv.tv_usec += USEC_PER_SEC * (tv.tv_sec - mlc->instart.tv_sec);
- if (tv.tv_usec - mlc->instart.tv_usec > mlc->intimeout) {
+
+ if (time_after(jiffies,
+ mlc->instart + usecs_to_jiffies(mlc->intimeout))) {
/* printk("!%i %i",
tv.tv_usec - mlc->instart.tv_usec,
mlc->intimeout);
diff --git a/include/linux/hil_mlc.h b/include/linux/hil_mlc.h
index 29bb5e3..feb167d 100644
--- a/include/linux/hil_mlc.h
+++ b/include/linux/hil_mlc.h
@@ -144,7 +144,7 @@ struct hil_mlc {
hil_packet ipacket[16];
hil_packet imatch;
int icount;
- struct timeval instart;
+ unsigned long instart; /* in jiffies */
suseconds_t intimeout;
int ddi;/* Last operational device id */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 1/2] hil_mlc: convert timeval to time64_t
Since mlc->lcv_t is only interested in seconds,
directly using time64_t here
Signed-off-by: WEN Pingbo
---
Version 2:
Convert timeval to ktime_t
Version 3:
Convert it to time64_t, since it's a better choice
drivers/input/serio/hil_mlc.c | 8 +++-
include/linux/hil_mlc.h | 2 +-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/input/serio/hil_mlc.c b/drivers/input/serio/hil_mlc.c
index 65605e4..fb297aa 100644
--- a/drivers/input/serio/hil_mlc.c
+++ b/drivers/input/serio/hil_mlc.c
@@ -274,14 +274,12 @@ static int hilse_match(hil_mlc *mlc, int unused)
/* An LCV used to prevent runaway loops, forces 5 second sleep when reset. */
static int hilse_init_lcv(hil_mlc *mlc, int unused)
{
- struct timeval tv;
+ time64_t now = ktime_get_seconds();
- do_gettimeofday(&tv);
-
- if (mlc->lcv && (tv.tv_sec - mlc->lcv_tv.tv_sec) < 5)
+ if (mlc->lcv && (now - mlc->lcv_t) < 5)
return -1;
- mlc->lcv_tv = tv;
+ mlc->lcv_t = now;
mlc->lcv = 0;
return 0;
diff --git a/include/linux/hil_mlc.h b/include/linux/hil_mlc.h
index 394a840..29bb5e3 100644
--- a/include/linux/hil_mlc.h
+++ b/include/linux/hil_mlc.h
@@ -149,7 +149,7 @@ struct hil_mlc {
int ddi;/* Last operational device id */
int lcv;/* LCV to throttle loops */
- struct timeval lcv_tv; /* Time loop was started */
+ time64_tlcv_t; /* Time loop was started */
int di_map[7]; /* Maps below items to live devs */
struct hil_mlc_devinfo di[HIL_MLC_DEVMEM];
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH net-next] net/core: initial support for stacked dev feature toggles
There are some netdev features that make little sense to toggle on and
off in a stacked device setup on only one device in the stack. The prime
example is a bonded connection, where it really doesn't make sense to
disable LRO on the master, but not on any of the slaves, nor does it
really make sense to be able to shut LRO off on a slave when its still
enabled on the master.
The strategy here is to add a section near the end of
netdev_fix_features() that looks for upper and lower netdevs, then make
sure certain feature flags match both up and down the stack. At present,
only the LRO flag is included.
This has been successfully tested with bnx2x, qlcnic and netxen network
cards as slaves in a bond interface. Turning LRO on or off on the master
also turns it on or off on each of the slaves, new slaves are added with
LRO in the same state as the master, and LRO can't be toggled on the
slaves.
Also, this should largely remove the need for dev_disable_lro(), and most,
if not all, of its call sites can be replaced by simply making sure
NETIF_F_LRO isn't included in the relevant device's feature flags.
Note that this patch is driven by bug reports from users saying it was
confusing that bonds and slaves had different settings for the same
features, and while it won't be 100% in sync if a lower device doesn't
support a feature like LRO, I think this is a good step in the right
direction.
CC: "David S. Miller"
CC: Eric Dumazet
CC: Jay Vosburgh
CC: Veaceslav Falico
CC: Andy Gospodarek
CC: Jiri Pirko
CC: Nikolay Aleksandrov
CC: Michal Kubecek
CC: net...@vger.kernel.org
Signed-off-by: Jarod Wilson
---
net/core/dev.c | 57 +
1 file changed, 57 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 1225b4b..26f4e2d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6261,9 +6261,57 @@ static void rollback_registered(struct net_device *dev)
list_del(&single);
}
+static netdev_features_t netdev_sync_upper_features(struct net_device *lower,
+ struct net_device *upper, netdev_features_t features)
+{
+ netdev_features_t want = upper->wanted_features & lower->hw_features;
+
+ if (!(upper->wanted_features & NETIF_F_LRO)
+ && (features & NETIF_F_LRO)) {
+ netdev_info(lower, "Dropping LRO, upper dev %s has it off.\n",
+ upper->name);
+ features &= ~NETIF_F_LRO;
+ } else if ((want & NETIF_F_LRO) && !(features & NETIF_F_LRO)) {
+ netdev_info(lower, "Keeping LRO, upper dev %s has it on.\n",
+ upper->name);
+ features |= NETIF_F_LRO;
+ }
+
+ return features;
+}
+
+static void netdev_sync_lower_features(struct net_device *upper,
+ struct net_device *lower, netdev_features_t features)
+{
+ netdev_features_t want = features & lower->hw_features;
+
+ if (!(features & NETIF_F_LRO) && (lower->features & NETIF_F_LRO)) {
+ netdev_info(upper, "Disabling LRO on lower dev %s.\n",
+ lower->name);
+ upper->wanted_features &= ~NETIF_F_LRO;
+ lower->wanted_features &= ~NETIF_F_LRO;
+ netdev_update_features(lower);
+ if (unlikely(lower->features & NETIF_F_LRO))
+ netdev_WARN(upper, "failed to disable LRO on %s!\n",
+ lower->name);
+ } else if ((want & NETIF_F_LRO) && !(lower->features & NETIF_F_LRO)) {
+ netdev_info(upper, "Enabling LRO on lower dev %s.\n",
+ lower->name);
+ upper->wanted_features |= NETIF_F_LRO;
+ lower->wanted_features |= NETIF_F_LRO;
+ netdev_update_features(lower);
+ if (unlikely(!(lower->features & NETIF_F_LRO)))
+ netdev_WARN(upper, "failed to enable LRO on %s!\n",
+ lower->name);
+ }
+}
+
static netdev_features_t netdev_fix_features(struct net_device *dev,
netdev_features_t features)
{
+ struct net_device *upper, *lower;
+ struct list_head *iter;
+
/* Fix illegal checksum combinations */
if ((features & NETIF_F_HW_CSUM) &&
(features & (NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM))) {
@@ -6318,6 +6366,15 @@ static netdev_features_t netdev_fix_features(struct
net_device *dev,
}
}
+ /* some features should be kept in sync with upper devices */
+ upper = netdev_master_upper_dev_get(dev);
+ if (upper)
+ features = netdev_sync_upper_features(dev, upper, features);
+
+ /* lower devices need some features altered to match upper devices */
+ netdev_for_each_lower_dev(dev, lower, iter)
+ netdev_sync_lower_features(dev, lower, features);
+
#ifdef CONFIG_NET_RX_BUSY_POLL
if (dev->netdev_ops->ndo_busy_poll)
features |= NETIF
[PATCH] ARM: dts: uniphier: add I2C aliases for ProXstream2 boards
Add aliases to fix the I2C indexes like the other UniPhier boards. Signed-off-by: Masahiro Yamada --- arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 4 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts | 4 2 files changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts index 5cb58b6..9d7ec5c 100644 --- a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts +++ b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts @@ -62,6 +62,10 @@ serial0 = &serial0; serial1 = &serial1; serial2 = &serial2; + i2c0 = &i2c0; + i2c4 = &i2c4; + i2c5 = &i2c5; + i2c6 = &i2c6; }; }; diff --git a/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts b/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts index 76040bb..498acac 100644 --- a/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts +++ b/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts @@ -62,6 +62,10 @@ serial0 = &serial0; serial1 = &serial1; serial2 = &serial2; + i2c0 = &i2c0; + i2c4 = &i2c4; + i2c5 = &i2c5; + i2c6 = &i2c6; }; }; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] ARM: dts: uniphier: delete i2c aliases
2015-10-24 5:16 GMT+09:00 Arnd Bergmann : > On Wednesday 21 October 2015 20:36:28 Masahiro Yamada wrote: >> The user space should not expect that a particular I2C channel is >> always visible through the same character device. >> No reason to fix the I2C indexes with aliases. >> >> Signed-off-by: Masahiro Yamada >> > > As I said in my reply to the earlier mail, I didn't really like the > idea of having holes in the numbering for the i2c controllers, but > this new approach also doesn't look ideal. > > We should have stable bus numbers on any given board, and the aliases > work well for that. I just don't think the aliases need to be stable > between different boards just because they are based on the same > SoC. > > I'd suggest staying with the current slightly awkward approach though, > to avoid regressions. Please send a follow-up patch to add the same > aliases on the new boards and drop this patch, unless someone else > can come up with a better idea. > OK, will do. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 16/17] drm: bridge: analogix/dp: move hpd detect to connector detect function
This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Take Jingoo suggest, add commit messages.
Changes in v3:
- move dp hpd detect to connector detect function.
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 3842dbd..216d33d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to disable the panel\n");
}
- ret = analogix_dp_detect_hpd(dp);
- if (ret) {
- /* Cable has been disconnected, we're done */
- return;
- }
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp->dev, "unable to handle edid\n");
@@ -941,6 +935,11 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
enum drm_connector_status analogix_dp_detect(struct device *dev, bool force)
{
+ struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+ if (analogix_dp_detect_hpd(dp))
+ return connector_status_disconnected;
+
return connector_status_connected;
}
EXPORT_SYMBOL_GPL(analogix_dp_detect);
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 17/17] drm: bridge: analogix/dp: add edid modes parse in get_modes method
Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Call drm_panel_prepare() in .get_modes function, ensure panel should
power on before driver try to read edid message.
Changes in v3:
- Add edid modes parse support
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 24 +++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 46 +++---
2 files changed, 40 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 216d33d..4fa5f69 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -107,7 +107,7 @@ static unsigned char
analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
static int analogix_dp_read_edid(struct analogix_dp_device *dp)
{
- unsigned char edid[EDID_BLOCK_LENGTH * 2];
+ unsigned char *edid = dp->edid;
unsigned int extend_block = 0;
unsigned char sum;
unsigned char test_vector;
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to disable the panel\n");
}
- ret = analogix_dp_handle_edid(dp);
- if (ret) {
- dev_err(dp->dev, "unable to handle edid\n");
- return;
- }
-
ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
dp->video_info.max_link_rate);
if (ret) {
@@ -947,8 +941,24 @@ EXPORT_SYMBOL_GPL(analogix_dp_detect);
int analogix_dp_get_modes(struct device *dev)
{
struct analogix_dp_device *dp = dev_get_drvdata(dev);
+ struct edid *edid = (struct edid *)dp->edid;
int num_modes = 0;
+ if (dp->plat_data && dp->plat_data->panel) {
+ if (drm_panel_prepare(dp->plat_data->panel)) {
+ DRM_ERROR("failed to setup the panel\n");
+ return -EINVAL;
+ }
+ }
+
+ if (analogix_dp_handle_edid(dp)) {
+ dev_err(dp->dev, "unable to handle edid\n");
+ return -EINVAL;
+ }
+
+ drm_mode_connector_update_edid_property(dp->connector, edid);
+ num_modes += drm_add_edid_modes(dp->connector, edid);
+
if (dp->plat_data->panel)
num_modes += drm_panel_get_modes(dp->plat_data->panel);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index d3c7e0a..2bd2e0d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,28 @@
#define MAX_CR_LOOP 5
#define MAX_EQ_LOOP 5
+/* I2C EDID Chip ID, Slave Address */
+#define I2C_EDID_DEVICE_ADDR 0x50
+#define I2C_E_EDID_DEVICE_ADDR 0x30
+
+#define EDID_BLOCK_LENGTH 0x80
+#define EDID_HEADER_PATTERN0x00
+#define EDID_EXTENSION_FLAG0x7e
+#define EDID_CHECKSUM 0x7f
+
+/* DP_MAX_LANE_COUNT */
+#define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
+#define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
+
+/* DP_LANE_COUNT_SET */
+#define DPCD_LANE_COUNT_SET(x) ((x) & 0x1f)
+
+/* DP_TRAINING_LANE0_SET */
+#define DPCD_PRE_EMPHASIS_SET(x) (((x) & 0x3) << 3)
+#define DPCD_PRE_EMPHASIS_GET(x) (((x) >> 3) & 0x3)
+#define DPCD_VOLTAGE_SWING_SET(x) (((x) & 0x3) << 0)
+#define DPCD_VOLTAGE_SWING_GET(x) (((x) >> 0) & 0x3)
+
enum link_rate_type {
LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
@@ -161,6 +183,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolneed_force_hpd;
+ unsigned char edid[EDID_BLOCK_LENGTH * 2];
struct analogix_dp_plat_data *plat_data;
};
@@ -260,27 +283,4 @@ int analogix_dp_is_video_stream_on(struct
analogix_dp_device *dp);
void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp);
void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
-
-/* I2C EDID Chip ID, Slave Address */
-#define I2C_EDID_DEVICE_ADDR 0x50
-#define I2C_E_EDID_DEVICE_ADDR 0x30
-
-#define EDID_BLOCK_LENGTH 0x80
-#define EDID_HEADER_PATTERN0x00
-#define EDID_EXTENSION_FLAG0x7e
-#define EDID_CHECK
Re: [PATCH] timer: Lazily wakup nohz CPU when adding new timer.
On 23-10-15, 15:10, Yunhong Jiang wrote: > I got this impression from Frederic's comments on > http://marc.info/?l=linux-kernel&m=139048415303210&w=2, "So you simply rely > on the next tick to see the new timer. This should work with > CONFIG_NO_HZ_IDLE but not with CONFIG_NO_HZ_FULL since the target may be > running without the tick". > Per my understanding of this comment, it means we can rely on the next tick > for CONFIG_NO_HZ_IDLE, which means it's sure a tick will happen for > CONFIG_NO_HZ_IDLE, am I right? Yeah, the CPU wouldn't like in idle for ever but the time is not known and it can be really really long. > Hmm, per http://lxr.free-electrons.com/source/include/linux/timer.h#L51, the > deferreable timer will be serviced when the CPU eventually wakes up "with a > subsequent non-deferrable timer". It will be an IPI mostly.. > If there is no non-deferrable timer, based > on Frederic's comments, we in fact depends on next tick. So, the cpu will wake up when it receives an IPI. The first thing we do then is to restart the tick and we will then service all the pending deferred timers. > My confusion is, why we are sure there is next tick on CONFIG_NO_HZ_IDLE > idle processor to wake it up. If there is no tick, and no other timer, will > the timer get no chance to be waken up at all? I don't think "deferred for > ever" is deferreable. There are many kind of works we may want to do. If its really important to be done earlier, then it should be serviced with a timer. deferred timers are better used for activities, which are irrelevant once the CPU is idle. One case is doing some per-cpu load tracking for cpufreq governors or the work that vmstat does. Even if the CPU wakes up after few hours (hypothetically), it shouldn't matter. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/4] ASoC: Add codec machine driver for RK3036
Mark & Sjoerd, On 2015年10月20日 03:13, Mark Brown wrote: On Tue, Oct 13, 2015 at 09:01:08AM +0800, Shunqian Zheng wrote: From: ZhengShunQian This patch add the machine driver for rk3036. Like Sjoerd said this looks like it migh be better just using simple-card, if not... Yes, simple-card works fine, I think I need to learn more and resend patches. Thank you very much, Shunqian + ret = snd_soc_dai_set_fmt(codec_dai, dai_fmt); + if (ret < 0) + return ret; + + /* set cpu DAI configuration */ + ret = snd_soc_dai_set_fmt(cpu_dai, dai_fmt); Set this in the dai_link struct. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/4] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
On Sat, Oct 24, 2015 at 12:56 AM, Karsten Merker wrote:
> On Fri, Oct 23, 2015 at 11:56:35PM +0800, Chen-Yu Tsai wrote:
>> On Fri, Oct 23, 2015 at 11:46 PM, Chen-Yu Tsai wrote:
>> > On Fri, Oct 23, 2015 at 10:53 PM, Karsten Merker wrote:
>> >> On Fri, Oct 23, 2015 at 11:50:41AM +0800, Chen-Yu Tsai wrote:
> [...]
>> >>> +/ {
>> >>> + model = "MSI Primo81 tablet";
>> >>> + compatible = "msi,primo81", "allwinner,sun6i-a31s";
>> >>> +};
> [...]
>> >>> +&i2c1 {
>> >>> + pinctrl-names = "default";
>> >>> + pinctrl-0 = <&i2c1_pins_a>;
>> >>> + status = "okay";
>> >>> +
>> >>> + ctp@5d {
>> >>> + pinctrl-names = "default";
>> >>> + pinctrl-0 = <>911_int_primo81>;
>> >>> + compatible = "goodix,gt911";
>> >>> + reg = <0x5d>;
>> >>> + interrupt-parent = <&pio>;
>> >>> + interrupts = <0 3 IRQ_TYPE_LEVEL_HIGH>; /* PA3 */
>> >>
>> >> I'd like to add a
>> >>
>> >> touchscreen-swapped-x-y = "true";
>> >>
>> >> as described in
>> >> Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>> >> here, as the display is in portrait mode while the touchscreen is
>> >> in landscape mode and needs to have the x and y axes swapped to
>> >> work in the same coordinate system as the display.
>> >>
>> >> Regarding the driver side: the goodix driver in kernel 4.3
>> >> doesn't yet support this property, but patches to add support for
>> >> it are on the linux-input list and should hopefully make it into
>> >> kernel 4.4.
>> >
>> > The DTS is already in Maxime's tree, and in sunxi-next. Feel free to
>> > send a follow-up patch adding them. I was waiting for those patches
>> > to be merged.
>>
>> Sorry, spoke too soon. Maxime hasn't pushed it out yet. Could you send
>> a patch adding touchscreen-swapped-x-y for Maxime to squash in?
>
> I'm happy to do so, but I have just stumbled over a problem with
> actually building the dtb for testing - it fails with
>
> arch/arm/boot/dts/sun6i-a31s-primo81.dts:242.1-14 Label or path
> simplefb_lcd not found
>
> The dts references simplefb_lcd:
>
> +&simplefb_lcd {
> + vcc-lcd-supply = <®_dc1sw>;
> + vdd-mipi-bridge-supply = <®_eldo3>;
> +};
>
> but I don't see where it would be defined. This is on the current
> sunxi/for-next branch of
> https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git
> with the Primo81 dts patch on top. Am I perhaps missing some
> required additional patch here?
Yes. The previous patch that adds labels to the simplefb nodes.
Both patches are now in sunxi/for-next in Maxime's tree now.
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.1 00/46] 4.1.12-stable review
On 10/23/2015 10:45 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.1.12 release.
There are 46 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Oct 25 17:46:11 UTC 2015.
Anything received after that time might be too late.
Build results:
total: 137 pass: 135 fail: 2
Failed builds:
powerpc:defconfig
powerpc:allmodconfig
Qemu test results:
total: 93 pass: 92 fail: 1
Failed tests:
powerpc:pseries_defconfig
Applying c56dadf39761 ("sched/preempt, powerpc, kvm: Use need_resched()
instead of should_resched()") should fix the problem.
Details are available at http://server.roeck-us.net:8010/builders.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI: race condition between scsi_remove_target and scsi_probe_and_add_lun
+ linux-scsi
> On Mar 20, 2014, at 6:42 PM, Andrey Zonov wrote:
>
> Hi,
>
> I've got kernel panic on my box which works as FibreChannel initiator.
> I was able to reproduce this panic by setting dev_loss_tmo=2 and
> enabling/disabling ports every 5 seconds on the switch in 5 minutes. I
> added some debug points in the kernel code and that's what I've got so far:
>
> 1. system is inserting new device into __devices list
>
> DEBUG: scsi_sysfs_device_initialize(): sdev=88046a931000 7:0:5:0
> Pid: 910, comm: kworker/u:2 Tainted: P O 3.2.48-swt9004 #33
> Call Trace:
> [] ? scsi_alloc_sdev+0x1d2/0x240
> [] ? scsi_device_lookup_by_target+0x8d/0xc0
> [] ? scsi_probe_and_add_lun+0x42a/0xb20
> [] ? kobject_set_name_vargs+0x6d/0x80
> [] ? dev_set_name+0x3f/0x50
> [] ? kobject_get+0x12/0x20
> [] ? fc_host_match+0x14/0x70 [scsi_transport_fc]
> [] ? attribute_container_add_device+0x4f/0x160
> [] ? kobject_get+0x12/0x20
> [] ? get_device+0x14/0x20
> [] ? scsi_alloc_target+0x295/0x2d0
> [] ? device_release+0x1a/0x80
> [] ? __scsi_scan_target+0xce/0x5f0
> [] ? dequeue_task_fair+0x52/0x150
> [] ? __schedule+0x25d/0x7d0
> [] ? scsi_scan_target+0xc6/0xe0
> [] ? fc_scsi_scan_rport+0xaf/0xc0 [scsi_transport_fc]
> [] ? process_one_work+0x116/0x3a0
> [] ? worker_thread+0x14c/0x400
> [] ? rescuer_thread+0x310/0x310
> [] ? rescuer_thread+0x310/0x310
> [] ? kthread+0x96/0xa0
> [] ? kernel_thread_helper+0x4/0x10
> [] ? kthread_worker_fn+0x120/0x120
> [] ? gs_change+0xb/0xb
>
> 2. later in scsi_probe_and_add_lun() this device is removing
>
> DEBUG: __scsi_remove_device(): sdev=88046a931000 7:0:5:0
> Pid: 910, comm: kworker/u:2 Tainted: P O 3.2.48-swt9004 #33
> Call Trace:
> [] ? __scsi_remove_device+0x46/0x110
> [] ? scsi_probe_and_add_lun+0x458/0xb20
> [] ? dev_set_name+0x3f/0x50
> [] ? kobject_get+0x12/0x20
> [] ? scsi_alloc_target+0x295/0x2d0
> [] ? device_release+0x1a/0x80
> [] ? __scsi_scan_target+0xce/0x5f0
> [] ? dequeue_task_fair+0x52/0x150
> [] ? __schedule+0x25d/0x7d0
> [] ? scsi_scan_target+0xc6/0xe0
> [] ? fc_scsi_scan_rport+0xaf/0xc0 [scsi_transport_fc]
> [] ? process_one_work+0x116/0x3a0
> [] ? worker_thread+0x14c/0x400
> [] ? rescuer_thread+0x310/0x310
> [] ? rescuer_thread+0x310/0x310
> [] ? kthread+0x96/0xa0
> [] ? kernel_thread_helper+0x4/0x10
> [] ? kthread_worker_fn+0x120/0x120
> [] ? gs_change+0xb/0xb
>
> 3. another thread is trying to remove this device because of timeout
>
> DEBUG: __scsi_remove_device(): sdev=88046a931000 7:0:5:0
> Pid: 4, comm: kworker/0:0 Tainted: P O 3.2.48-swt9004 #33
> Call Trace:
> [] ? __scsi_remove_device+0x46/0x110
> [] ? mutex_lock+0x1a/0x40
> [] ? scsi_remove_device+0x28/0x40
> [] ? scsi_kmap_atomic_sg+0x180/0x180
> [] ? scsi_remove_target+0x141/0x1e0
> [] ? process_one_work+0x116/0x3a0
> [] ? worker_thread+0x14c/0x400
> [] ? rescuer_thread+0x310/0x310
> [] ? rescuer_thread+0x310/0x310
> [] ? kthread+0x96/0xa0
> [] ? kernel_thread_helper+0x4/0x10
> [] ? kthread_worker_fn+0x120/0x120
> [] ? gs_change+0xb/0xb
>
> and it's got dead sdev object. I don't understand how this can happen
> because __scsi_remove_target() iterating over __devices and getting sdev
> reference under host_lock and that should be enough.
>
> DEBUG: kref_put(): kref=88046a9312e0 val=-1
> [ cut here ]
> WARNING: at lib/kref.c:61 kref_put+0x88/0xc0()
> Hardware name: X9DRi-LN4+/X9DR3-LN4+
> Modules linked in: qla2xxx(O) igb ehci_hcd scsi_transport_fc
> Pid: 4, comm: kworker/0:0 Tainted: P O 3.2.48-swt9004 #33
> Call Trace:
> [] ? warn_slowpath_common+0x7b/0xc0
> [] ? kobject_del+0x30/0x30
> [] ? kref_put+0x88/0xc0
> [] ? __scsi_remove_device+0x8c/0x110
> [] ? mutex_lock+0x1a/0x40
> [] ? scsi_remove_device+0x28/0x40
> [] ? scsi_kmap_atomic_sg+0x180/0x180
> [] ? scsi_remove_target+0x141/0x1e0
> [] ? process_one_work+0x116/0x3a0
> [] ? worker_thread+0x14c/0x400
> [] ? rescuer_thread+0x310/0x310
> [] ? rescuer_thread+0x310/0x310
> [] ? kthread+0x96/0xa0
> [] ? kernel_thread_helper+0x4/0x10
> [] ? kthread_worker_fn+0x120/0x120
> [] ? gs_change+0xb/0xb
>
> Here is the patch which helped me:
>
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 9117d0b..676e5ff 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1094,6 +1094,7 @@ static void __scsi_remove_target(struct
> scsi_target *starget)
>unsigned long flags;
>struct scsi_device *sdev;
>
> + mutex_lock(&shost->scan_mutex);
>spin_lock_irqsave(shost->host_lock, flags);
> restart:
>list_for_each_entry(sdev, &shost->__devices, siblings) {
> @@ -1102,12 +1103,13 @@ static void __scsi_remove_target(struct
> scsi_target *starget)
>scsi_device_get(sdev))
>continue;
>spin_unlock_irqrestore(shost->host_lock, flags);
> - scsi_remove_device(sdev);
> + __scsi_remove_device(sdev);
>scsi_device_
[PATCH v7 14/17] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288
There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Seprate the link-rate and lane-count limit out with the device_type
flag. (Thierry)
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 33 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 4 +--
2 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6307060..563ffb1d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
return;
}
- ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
-dp->video_info.link_rate);
+ ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
+dp->video_info.max_link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1156,16 +1156,25 @@ static int analogix_dp_dt_parse_pdata(struct
analogix_dp_device *dp)
struct device_node *dp_node = dp->dev->of_node;
struct video_info *video_info = &dp->video_info;
- if (of_property_read_u32(dp_node, "samsung,link-rate",
-&video_info->link_rate)) {
- dev_err(dp->dev, "failed to get link-rate\n");
- return -EINVAL;
- }
-
- if (of_property_read_u32(dp_node, "samsung,lane-count",
-&video_info->lane_count)) {
- dev_err(dp->dev, "failed to get lane-count\n");
- return -EINVAL;
+ switch (dp->plat_data && dp->plat_data->dev_type) {
+ case RK3288_DP:
+ /*
+* Like Rk3288 DisplayPort TRM indicate that "Main link
+* containing 4 physical lanes of 2.7/1.62 Gbps/lane".
+*/
+ video_info->max_link_rate = 0x0A;
+ video_info->max_lane_count = 0x04;
+ break;
+ case EXYNOS_DP:
+ /*
+* NOTE: those property parseing code is used for
+* providing backward compatibility for samsung platform.
+*/
+ of_property_read_u32(dp_node, "samsung,link-rate",
+&video_info->max_link_rate);
+ of_property_read_u32(dp_node, "samsung,lane-count",
+&video_info->max_lane_count);
+ break;
}
return 0;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index e37cef6..e6f8243 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -129,8 +129,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
- enum link_rate_type link_rate;
- enum link_lane_count_type lane_count;
+ enum link_rate_type max_link_rate;
+ enum link_lane_count_type max_lane_count;
};
struct link_train {
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 12/17] drm: rockchip: vop: add bpc and color mode setting
From: Mark Yao
Add bpc and color mode setting in rockchip_drm_vop driver, so
connector could try to use the edid drm_display_info to config
vop output mode.
Signed-off-by: Mark Yao
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- Fix compiled error (Heiko)
- Using the connector display info message to configure eDP driver input
video mode, but hard code CRTC video output mode to RGBaaa.
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25 +++
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 32 ++---
4 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 2c82a9a..3990951 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -180,14 +180,29 @@ static void rockchip_dp_drm_encoder_mode_set(struct
drm_encoder *encoder,
static void rockchip_dp_drm_encoder_prepare(struct drm_encoder *encoder)
{
struct rockchip_dp_device *dp = to_dp(encoder);
+ struct drm_connector *cn = &dp->connector;
+ int ret = -1;
u32 val;
- int ret;
- ret = rockchip_drm_crtc_mode_config(encoder->crtc,
- DRM_MODE_CONNECTOR_eDP,
- ROCKCHIP_OUT_MODE_);
+ /*
+* FIXME(Yakir): driver should configure the CRTC output video
+* mode with the display information which indicated the monitor
+* support colorimetry.
+*
+* But don't know why the CRTC driver seems could only output the
+* RGBaaa rightly. For example, if connect the "innolux,n116bge"
+* eDP screen, EDID would indicated that screen only accepted the
+* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
+* screen would show a blue picture (RGB888 show a green picture).
+* But if I configure CTRC to RGBaaa, and eDP driver still keep
+* RGB666 input video mode, then screen would works prefect.
+*/
+ if (cn->display_info.color_formats & DRM_COLOR_FORMAT_RGB444)
+ ret = rockchip_drm_crtc_mode_config(encoder->crtc,
+ DRM_MODE_CONNECTOR_eDP,
+ 10, DRM_COLOR_FORMAT_RGB444);
if (ret < 0) {
- dev_err(dp->dev, "Could not set crtc mode config: %d.\n", ret);
+ dev_err(dp->dev, "Could not set crtc mode config (%d)\n", ret);
return;
}
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 80d6fc8..428a3c1 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -215,7 +215,7 @@ static void dw_hdmi_rockchip_encoder_commit(struct
drm_encoder *encoder)
static void dw_hdmi_rockchip_encoder_prepare(struct drm_encoder *encoder)
{
rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
- ROCKCHIP_OUT_MODE_);
+ 10, DRM_COLOR_FORMAT_RGB444);
}
static struct drm_encoder_helper_funcs dw_hdmi_rockchip_encoder_helper_funcs =
{
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index dc4e5f0..ef1d7fb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -59,7 +59,7 @@ void rockchip_unregister_crtc_funcs(struct drm_device *dev,
int pipe);
int rockchip_drm_encoder_get_mux_id(struct device_node *node,
struct drm_encoder *encoder);
int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int connector_type,
- int out_mode);
+ int bpc, int color);
int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
struct device *dev);
void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 5d8ae5e..9ef4a1f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1062,14 +1062,40 @@ static const struct drm_plane_funcs vop_plane_funcs = {
int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
int connector_type,
- int out_mode)
+ int bpc, int color)
{
struct vop *vop = to_vop(crtc);
+ /*
+* RK3288 vop only support RGB Color output.
+*/
+ if
[PATCH v7 13/17] drm: bridge: analogix/dp: add some rk3288 special registers setting
RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fix compile failed dut to phy_pd_addr variable misspell error
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 76 ++-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 12
2 files changed, 60 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 861097a..21a3287 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -15,6 +15,8 @@
#include
#include
+#include
+
#include "analogix_dp_core.h"
#include "analogix_dp_reg.h"
@@ -72,6 +74,14 @@ void analogix_dp_init_analog_param(struct analogix_dp_device
*dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
+ if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+ writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+ writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
+ writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
+ writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
+ writel(0x22, dp->reg_base + ANALOGIX_DP_PLL_REG_5);
+ }
+
reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);
@@ -206,81 +216,85 @@ void analogix_dp_set_analog_power_down(struct
analogix_dp_device *dp,
bool enable)
{
u32 reg;
+ u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+
+ if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+ phy_pd_addr = ANALOGIX_DP_PD;
switch (block) {
case AUX_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= AUX_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~AUX_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH0_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH0_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH0_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH1_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH1_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH1_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH2_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH2_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH2_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH3_BLOCK:
[PATCH v7 15/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
hpd when hpd detect failed.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 4 ++-
.../bindings/display/exynos/exynos_dp.txt | 1 +
.../display/rockchip/analogix_dp-rockchip.txt | 1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 36 +++---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++
6 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..74f0e80 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".
Optional properties for dp-controller:
+ -analogix,need-force-hpd:
+ Indicate driver need force hpd when hpd detect failed, this
+ is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
*
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
-
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
---
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 9e47357..e9b0548 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP binding
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+ -analogix,need-force-hpd (optional)
-video interfaces (optional)
Deprecated properties for DisplayPort:
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index ec93917..be18388 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -31,6 +31,7 @@ For the below properties, please refer to Analogix DP binding
document:
- phys (required)
- phy-names (required)
- hpd-gpios (optional)
+- analogix,need-force-hpd (optional)
---
Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 563ffb1d..3842dbd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
{
int timeout_loop = 0;
- while (analogix_dp_get_plug_in_status(dp) != 0) {
+ while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+ if (analogix_dp_get_plug_in_status(dp) == 0)
+ return 0;
+
timeout_loop++;
- if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
- dev_err(dp->dev, "failed to get hpd plug status\n");
- return -ETIMEDOUT;
- }
usleep_range(10, 11);
}
+ /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "need-force-hpd" would indicate whether driver need this.
+*/
+ if (!dp->need_force_hpd)
+ return -ETIMEDOUT;
+
+ /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give a force hpd action to
+* set HPD_STATUS manually.
+*/
+ dev_dbg(dp->dev, "failed to get hpd plug status, try to force hpd\n");
+
+ analogix_dp_force_hpd(dp);
+
+ if (analogix_dp_get_plug_in_status(dp) != 0) {
+ dev_err(dp->dev, "failed to get hpd plug in status\n");
+
[PATCH v7 11/17] Documentation: phy: add document for rockchip dp phy
Add dt binding documentation for rockchip display port PHY.
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
elemets in document. (Rob & Heiko)
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..505194e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,22 @@
+Rockchip Soc Seroes Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "24m"
+- rockchip,grf: phandle to the syscon managing the "general register files"
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: edp-phy@ff770274 {
+ compatible = "rockchip,rk3288-dp-phy";
+ rockchip,grf = <&grf>;
+ clocks = <&cru SCLK_EDP_24M>;
+ clock-names = "24m";
+ #phy-cells = <0>;
+};
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 10/17] phy: Add driver for rockchip Display Port PHY
Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6:
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)
Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
the exist "grf" syscon already. And rename the example DT node from
"edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
struct" to "static const struct". And correct the input paramters of
devm_phy_create() interfaces. (Heiko)
Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
function, move those code to probe() method. And remove driver .owner
number. (Kishon)
Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
power control. (Heiko)
Changes in v2: None
drivers/phy/Kconfig | 7 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-rockchip-dp.c | 153 ++
3 files changed, 161 insertions(+)
create mode 100644 drivers/phy/phy-rockchip-dp.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 7eb5859d..7355819 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -319,6 +319,13 @@ config PHY_ROCKCHIP_USB
help
Enable this to support the Rockchip USB 2.0 PHY.
+config PHY_ROCKCHIP_DP
+ tristate "Rockchip Display Port PHY Driver"
+ depends on ARCH_ROCKCHIP && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the Rockchip Display Port PHY.
+
config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 075db1a..b1700cd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -35,6 +35,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..4af19af
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,153 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GRF_SOC_CON12 0x0274
+#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
+#define GRF_EDP_PHY_SIDDQ_WRITE_EN BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF BIT(5)
+
+struct rockchip_dp_phy {
+ struct device *dev;
+ struct regmap *grf;
+ struct clk *phy_24m;
+};
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+ struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+ int ret;
+
+ if (enable) {
+ ret = regmap_write(dp->grf, GRF_SOC_CON12,
+ GRF_EDP_PHY_SIDDQ_WRITE_EN |
+ GRF_EDP_PHY_SIDDQ_ON);
+ if (ret < 0) {
+ dev_err(dp->dev, "Can't enable PHY power %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(dp->phy_24m);
+
+ } else {
+ clk_disable_unprepare(dp->phy_24m);
+
+ ret = regmap_write(dp->grf, GRF_SOC_CON12,
+ GRF_EDP_PHY_SIDDQ_WRITE_EN |
+ GRF_EDP_PHY_SIDDQ_OFF);
+ }
+
+ return ret;
+}
+
+static int rockchip_dp_phy_power_on(struct phy *phy)
+{
+ return rockchip_set_phy_state(phy, true);
+}
+
+static int rockchip_dp_phy_power_off(struct phy *phy)
+{
+ return rockchip_set_phy_state(phy, false);
+}
+
+static const struct phy_ops rockchip_dp_phy_ops = {
+ .power_on = rockchip_dp_phy_power_on,
+ .power_off = rockchip_dp_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int rockchip_dp_phy_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct phy_provide
[PATCH v7 09/17] Documentation: drm/bridge: add document for analogix_dp
Rockchip DP driver is a helper driver of analogix_dp coder driver,
so most of the DT property should be descriped in analogix_dp document.
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../display/rockchip/analogix_dp-rockchip.txt | 90 ++
1 file changed, 90 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
new file mode 100644
index 000..ec93917
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -0,0 +1,90 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+
+- clock-names: from common clock binding:
+ Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+
+- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
+- pinctrl-0: pin-control mode. should be <&edp_hpd>
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: contain a port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+---
+
+Example:
+ dp-controller: dp@ff97 {
+ compatible = "rockchip,rk3288-dp";
+ reg = <0xff97 0x4000>;
+ interrupts = ;
+ clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
+ clock-names = "dp", "pclk";
+ phys = <&dp_phy>;
+ phy-names = "dp";
+
+ rockchip,grf = <&grf>;
+ resets = <&cru 111>;
+ reset-names = "dp";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&edp_hpd>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_edp>;
+ };
+ edp_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_edp>;
+ };
+ };
+
+ edp_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_out_panel: endpoint {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>
+ };
+ };
+ };
+ };
+
+ pinctrl {
+ edp {
+ edp_hpd: edp-hpd {
+ rockchip,pins = <7 11 RK_FUNC_2
&pcfg_pull_none>;
+ };
+ };
+ };
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 06/17] Documentation: drm/bridge: add document for analogix_dp
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Split all DTS changes, and provide backward compatibility. Mark old
properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
"analogix,color-space" & "analogix,color-depth" &
"analogix,link-rate" & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high" & "interlaces"
Changes in v3:
- Add devicetree binding documents. (Heiko)
- Remove sync pol & colorimetry properies from the new analogix dp driver
devicetree binding. (Thierry)
- Update the exist exynos dtsi file with the latest DP DT properies.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 50 +
.../bindings/display/exynos/exynos_dp.txt | 63 --
2 files changed, 71 insertions(+), 42 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
new file mode 100644
index 000..7659a7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -0,0 +1,50 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+ -compatible:
+ platform specific such as:
+* "samsung,exynos5-dp"
+* "rockchip,rk3288-dp"
+ -reg:
+ physical base address of the controller and length
+ of memory mapped region.
+ -interrupts:
+ interrupt combiner values.
+ -clocks:
+ from common clock binding: handle to dp clock.
+ -clock-names:
+ from common clock binding: Shall be "dp".
+ -interrupt-parent:
+ phandle to Interrupt combiner node.
+ -phys:
+ from general PHY binding: the phandle for the PHY device.
+ -phy-names:
+ from general PHY binding: Should be "dp".
+
+Optional properties for dp-controller:
+ -hpd-gpios:
+ Hotplug detect GPIO.
+ Indicates which GPIO should be used for hotplug detection
+ -port@[X]: SoC specific port nodes with endpoint definitions as defined
+ in Documentation/devicetree/bindings/media/video-interfaces.txt,
+ please refer to the SoC specific binding document:
+ * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+ *
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+---
+
+Example:
+
+ dp-controller {
+ compatible = "samsung,exynos5-dp";
+ reg = <0x145b 0x1>;
+ interrupts = <10 3>;
+ interrupt-parent = <&combiner>;
+ clocks = <&clock 342>;
+ clock-names = "dp";
+
+ phys = <&dp_phy>;
+ phy-names = "dp";
+ };
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 7a3a9cd..9e47357 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -31,45 +31,31 @@ Required properties for dp-controller:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
- -samsung,color-space:
- input video data format.
- COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
- -samsung,dynamic-range:
- dynamic range for input video data.
- VESA = 0, CEA = 1
- -samsung,ycbcr-coeff:
- YCbCr co-efficients for input video.
- COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
- -samsung,color-depth:
- number of bits per colour component.
- COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
- -samsung,link-rate:
- link rate supported by the panel.
- LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
- -samsung,lane-count:
- number of lanes supported by the panel.
-
[PATCH v7 08/17] drm: rockchip: dp: add rockchip platform dp driver
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- Remove the empty line at the end of document, and correct the endpoint
numbers in the example DT node, and remove the regulator iomux setting
in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.
Changes in v3:
- Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
and leave "sclk_edp" to analogix dp core driver which name to "dp",
and leave "pclk_edp" to rockchip dp platform driver which name to
"pclk". (Thierry & Heiko)
- Add devicetree binding document. (Heiko)
- Remove "rockchip,panel" DT property, take use of remote point to get panel
node. (Heiko)
- Add the new function point dp_platdata->get_modes() init.
Changes in v2:
- Get panel node with remote-endpoint method, and create devicetree binding
for driver. (Heiko)
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
leave those clock to rockchip dp phy driver.
drivers/gpu/drm/rockchip/Kconfig| 9 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 442
include/drm/bridge/analogix_dp.h| 1 +
4 files changed, 453 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..c2ba945 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,12 @@ config ROCKCHIP_DW_HDMI
for the Synopsys DesignWare HDMI driver. If you want to
enable HDMI on RK3288 based SoC, you should selet this
option.
+
+config ROCKCHIP_ANALOGIX_DP
+tristate "Rockchip specific extensions for Analogix DP driver"
+depends on DRM_ROCKCHIP
+select DRM_ANALOGIX_DP
+help
+ This selects support for Rockchip SoC specific extensions
+ for the Analogix Core DP driver. If you want to enable DP
+ on RK3288 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index f3d8a19..8ad01fb 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,5 +6,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o
rockchip_drm_fbdev.o \
rockchip_drm_gem.o
obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
new file mode 100644
index 000..2c82a9a
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -0,0 +1,442 @@
+/*
+ * Rockchip SoC DP (Display Port) interface driver.
+ *
+ * Copyright (C) Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Andy Yan
+ * Yakir Yang
+ * Jeff Chen
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define to_dp(nm) container_of(nm, struct rockchip_dp_device, nm)
+
+/* dp grf register offset */
+#define GRF_SOC_CON60x025c
+#define GRF_EDP_LCD_SEL_MASKBIT(5)
+#define GRF_EDP_SEL_VOP_LIT BIT(5)
+#define GRF_EDP_SEL_VOP_BIG 0
+
+struct rockchip_dp_device {
+ struct drm_device*drm_dev;
+ struct device*dev;
+ struct drm_encoder encoder;
+ struct drm_connector connector;
+ struct drm_display_mode mode;
+
+ struct clk *pclk;
+ struct regmap*grf;
+ struct reset_control *rst;
+
+ struct analogix_dp_plat_data plat_data;
+};
+
+static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
+{
+ reset_control_assert(dp->rst);
+ usleep_range(10, 20);
+ reset_control_deassert(dp->rst);
+
+ return 0;
+}
+
+static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
+{
+ struct
[PATCH v7 07/17] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver
After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.
Beside the backward compatibility is fully preserved, so there are no
bisectability break that make this change in a separate patch.
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6:
- Fix Peach Pit hpd property name error:
- hpd-gpio = <&gpx2 6 0>;
+ hpd-gpios = <&gpx2 6 0>;
Changes in v5:
- Correct the misspell in commit message. (Krzysztof)
Changes in v4:
- Separate all DTS changes to a separate patch. (Krzysztof)
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/exynos5250-arndale.dts | 2 --
arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 --
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +---
arch/arm/boot/dts/exynos5250-spring.dts | 4 +---
arch/arm/boot/dts/exynos5420-peach-pit.dts| 4 +---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 --
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +---
7 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index c000532..b1790cf 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -124,8 +124,6 @@
&dp {
status = "okay";
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 0f5dcd4..f30c2db 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -80,8 +80,6 @@
&dp {
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 0a7f408..ee94110 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -236,12 +236,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
- samsung,hpd-gpio = <&gpx0 7 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx0 7 GPIO_ACTIVE_HIGH>;
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index c1edd6d..91881d7 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -74,12 +74,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd_gpio>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <1>;
- samsung,hpd-gpio = <&gpc3 0 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpc3 0 GPIO_ACTIVE_HIGH>;
};
&ehci {
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 72ba6f0..8baf40a 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -148,12 +148,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd_gpio>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
- samsung,hpd-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx2 6 GPIO_ACTIVE_HIGH>;
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index ac35aef..f67344f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -93,8 +93,6 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43..e5a4cd5 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -142,12 +142,1
Re: [PATCH v2] EDAC: Add ARM64 EDAC
On 2015/10/24 1:58, Brijesh Singh wrote: >> So I checked the x86 code: the driver is always loaded as soon as the >> hardware is there (looking at PCI device IDs from the on-chip >> northbridge, for instance). The trick here is to have the Kconfig option >> defaulting to "=n", so a kernel builder would have to explicitly enable >> this. Android or embedded kernels wouldn't do this, for instance, while >> a server distribution would do. >> If a user doesn't want to be bothered with the driver, there is always >> the possibility of blacklisting the module. >> Setting a system policy is IMHO out of scope for a DT binding. >> > Will update Kconfig to make it n by default. > * Its possible that other SoC's might handle single-bit and double-bit errors differently compare to Seattle platform. In Seattle platform both errors are handled by firmware but if other SoC wants OS to handle these errors then they might need DT binding to provide the irq numbers etc. >> What do you mean exactly with "firmware handles these errors"? >> What would the firmware do? I guess just logging the error and then >> possibly reset the register? How would this change the driver? >> > On Seattle platform SoC generates a interrupt on both single bit and double > bit error > and that interrupt is handled by firmware, so we don't need to do anything in > the driver. > Driver just need to poll registers to log correctable errors (because they do > not generate interrupt). > This very driver is doing exactly what we want. DT binding is not required. > > But Hanjun's comment on very first patch hinted me that there is possibility > that > SoC generate a interrupt on single bit and double bit but firmware does not > handle it. > In those cases driver will need be extended to handle interrupt. yes, exactly. > > I will submit v3 for review with DT binding removed. We can revisit DT > binding need in future. > >>> I totally agree with you here, thanks for putting them together. >>> Different SoCs may handle the error in different ways, we need >>> bindings to specialize them, irq number is a good example :) >> But how does this affect this very driver, polling just those two registers? >> Where would the interrupt come into the game here? Where is the proposed >> DT binding for that interrupt? >> >> AFAICT EL3 firmware handling errors would just hide this information >> from the driver, so if the f/w decides to "handle" uncorrectable ECC >> errors in a fatal way, there is nothing the driver could do anyway, right? Yes, if EL3 firmware is involved, the driver don't need to handle such interrupt. >> >> Can you sketch a concrete example where we would actually need the >> driver to know about the firmware capabilities? So if firmware don't handle it, just like the APM xgene did in xgene_edac.c, we need handle it in the driver, then DT bindings with irq number are needed. You know, I'm working on ACPI and will enthusiastically encourage people using APEI with firmware handle error first :) , but I think we can't rule out such cases (driver handle the errors). Thanks Hanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] staging: rdma: hfi1: Use setup_timer
Use the timer API function setup_timer instead of init_timer, removing the structure field assignments. @timer@ expression e1,e2,e3,fn_ptr; @@ -init_timer(&e1); +setup_timer(&e1, fn_ptr, e2); ... when != fn_ptr = e3 -e1.function = fn_ptr; -e1.data = e2; Signed-off-by: Muhammad Falak R Wani --- drivers/staging/rdma/hfi1/sdma.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/rdma/hfi1/sdma.c b/drivers/staging/rdma/hfi1/sdma.c index 63ab721..16d93ff 100644 --- a/drivers/staging/rdma/hfi1/sdma.c +++ b/drivers/staging/rdma/hfi1/sdma.c @@ -1094,10 +1094,8 @@ int sdma_init(struct hfi1_devdata *dd, u8 port) sde->progress_check_head = 0; - init_timer(&sde->err_progress_check_timer); - sde->err_progress_check_timer.function = - sdma_err_progress_check; - sde->err_progress_check_timer.data = (unsigned long)sde; + setup_timer(&sde->err_progress_check_timer, + sdma_err_progress_check, (unsigned long)sde); sde->descq = dma_zalloc_coherent( &dd->pcidev->dev, -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should audit_seccomp check audit_enabled?
On October 23, 2015 5:30:45 PM Andy Lutomirski wrote: On Fri, Oct 23, 2015 at 2:22 PM, Kees Cook wrote: On Fri, Oct 23, 2015 at 2:07 PM, Andy Lutomirski wrote: On Oct 23, 2015 10:01 AM, "Kees Cook" wrote: On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski wrote: > I would argue that, if auditing is off, audit_seccomp shouldn't do > anything. After all, unlike e.g. selinux, seccomp is not a systemwide > policy, and seccomp signals might be ordinary behavior that's internal > to the seccomp-using application. IOW, for people with audit compiled > in and subscribed by journald but switched off, I think that the > records shouldn't be emitted. > > If you agree, I can send the two-line patch. I think signr==0 states (which I would identify as "intended behavior") don't need to be reported under any situation, but audit folks wanted to keep it around. Even if there is a nonzero signr, it could just be a program opting to trap and emulate one of its own syscalls. At present, that is a rare situation. Programs tend to be ptrace managed externally. Is there anything catching SIGSYS itself? I wrote one once. I also wrote a whole set of patches for libseccomp to make it easier that never went anywhere -- I should dust those off and package them into their own library. It has been a while since we discussed those patches, but if I remember correctly it was going to be very difficult to do it in an arch agnostic way and that was a concern. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] staging: rdma: hfi1: Use setup_timer
Use the timer API function setup_timer instead of init_timer, removing
the structure field assignments.
@timer@
expression e1,e2,e3,fn_ptr;
@@
-init_timer(&e1);
+setup_timer(&e1, fn_ptr, e2);
... when != fn_ptr = e3
-e1.function = fn_ptr;
-e1.data = e2;
Signed-off-by: Muhammad Falak R Wani
---
drivers/staging/rdma/hfi1/driver.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rdma/hfi1/driver.c
b/drivers/staging/rdma/hfi1/driver.c
index c0a5900..ef4e0c5 100644
--- a/drivers/staging/rdma/hfi1/driver.c
+++ b/drivers/staging/rdma/hfi1/driver.c
@@ -1062,9 +1062,9 @@ void hfi1_set_led_override(struct hfi1_pportdata *ppd,
unsigned int val)
*/
if (atomic_inc_return(&ppd->led_override_timer_active) == 1) {
/* Need to start timer */
- init_timer(&ppd->led_override_timer);
- ppd->led_override_timer.function = run_led_override;
- ppd->led_override_timer.data = (unsigned long) ppd;
+ setup_timer(&ppd->led_override_timer, run_led_override,
+ (unsigned long)ppd);
+
ppd->led_override_timer.expires = jiffies + 1;
add_timer(&ppd->led_override_timer);
} else {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] staging: rdma: hfi1: Use setup_timer
Use the timer API function setup_timer instead of init_timer, removing
the structure field assignments.
@timer@
expression e1,e2,e3,fn_ptr;
@@
-init_timer(&e1);
+setup_timer(&e1, fn_ptr, e2);
... when != fn_ptr = e3
-e1.function = fn_ptr;
-e1.data = e2;
Signed-off-by: Muhammad Falak R Wani
---
drivers/staging/rdma/hfi1/chip.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rdma/hfi1/chip.c b/drivers/staging/rdma/hfi1/chip.c
index 46ebc38..c403957 100644
--- a/drivers/staging/rdma/hfi1/chip.c
+++ b/drivers/staging/rdma/hfi1/chip.c
@@ -2215,9 +2215,7 @@ static void update_rcverr_timer(unsigned long opaque)
static int init_rcverr(struct hfi1_devdata *dd)
{
- init_timer(&dd->rcverr_timer);
- dd->rcverr_timer.function = update_rcverr_timer;
- dd->rcverr_timer.data = (unsigned long) dd;
+ setup_timer(&dd->rcverr_timer, update_rcverr_timer, (unsigned long)dd);
/* Assume the hardware counter has been reset */
dd->rcv_ovfl_cnt = 0;
return mod_timer(&dd->rcverr_timer, jiffies + HZ * RCVERR_CHECK_TIME);
@@ -8156,9 +8154,8 @@ static int init_cntrs(struct hfi1_devdata *dd)
struct hfi1_pportdata *ppd;
/* set up the stats timer; the add_timer is done at the end */
- init_timer(&dd->synth_stats_timer);
- dd->synth_stats_timer.function = update_synth_timer;
- dd->synth_stats_timer.data = (unsigned long) dd;
+ setup_timer(&dd->synth_stats_timer, update_synth_timer,
+ (unsigned long)dd);
/***/
/* per device counters */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] hwmon: ina2xx: port to using remap, improve bandwidth.
On 10/23/2015 01:35 PM, Marc Titinger wrote:
Hi Guenter
thanks for the review, answers bellow.
Marc.
[ ... ]
-/*
- * Ina226 has a variable update_interval. For ina219 we
- * use a constant value.
+/* Check for shunt resistor value.
Another comment: Standard multi-line comments, please.
+ * Give precedence to device tree over must-recompile.
*/
-if (data->kind == ina226)
-ina226_set_update_interval(data);
-else
-data->update_interval = HZ / INA2XX_CONVERSION_RATE;
+if (of_property_read_u32(dev->of_node, "shunt-resistor", &val) < 0) {
+pdata = dev_get_platdata(dev);
+if (pdata)
+val = pdata->shunt_uohms;
+else
+val = INA2XX_RSHUNT_DEFAULT;
+}
This changes priority from platform data first to devicetree configuration
first.
As such, it is an unrelated change. If needed, split into a separate patch, and
Yes I would do a separate patch normaly, agreed.
explain the reasoning, please.
Changing the platform data requires changes in the kernel code, and hence
recompilation. It seems a bit unexpected that setting a new value in the dtb
will be ignored because there is a compiled-in platform data. Should'nt the dtb
allow to override platform data ?
Normally you would not _have_ platform data in a system which is dtb enabled.
I don't really mind changing priorities (you are right, it makes sense to
check for devicetree data first), but as mentioned as separate patch, please.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] staging: rdma: ipath: Use setup_timer
Use the timer API function setup_timer instead of init_timer, removing the structure field assignments. Signed-off-by: Muhammad Falak R Wani --- drivers/staging/rdma/ipath/ipath_verbs.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rdma/ipath/ipath_verbs.c b/drivers/staging/rdma/ipath/ipath_verbs.c index 40f7f05..fa8d02b 100644 --- a/drivers/staging/rdma/ipath/ipath_verbs.c +++ b/drivers/staging/rdma/ipath/ipath_verbs.c @@ -1956,9 +1956,8 @@ static int enable_timer(struct ipath_devdata *dd) dd->ipath_gpio_mask); } - init_timer(&dd->verbs_timer); - dd->verbs_timer.function = __verbs_timer; - dd->verbs_timer.data = (unsigned long)dd; + setup_timer(&dd->verbs_timer, __verbs_timer, (unsigned long)dd); + dd->verbs_timer.expires = jiffies + 1; add_timer(&dd->verbs_timer); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] staging: rdma: ipath: Use setup_timer
Use the timer API function setup_timer instead of init_timer, removing the structure field assignments. Signed-off-by: Muhammad Falak R Wani --- drivers/staging/rdma/ipath/ipath_sdma.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rdma/ipath/ipath_sdma.c b/drivers/staging/rdma/ipath/ipath_sdma.c index 17a5177..1ffc06a 100644 --- a/drivers/staging/rdma/ipath/ipath_sdma.c +++ b/drivers/staging/rdma/ipath/ipath_sdma.c @@ -400,9 +400,9 @@ static int alloc_sdma(struct ipath_devdata *dd) } dd->ipath_sdma_head_dma[0] = 0; - init_timer(&dd->ipath_sdma_vl15_timer); - dd->ipath_sdma_vl15_timer.function = vl15_watchdog_timeout; - dd->ipath_sdma_vl15_timer.data = (unsigned long)dd; + setup_timer(&dd->ipath_sdma_vl15_timer, vl15_watchdog_timeout, + (unsigned long)dd); + atomic_set(&dd->ipath_sdma_vl15_count, 0); goto done; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] staging: rdma: ipath: Use setup_timer
Use the timer API function setup_timer instead of init_timer, removing
the structure field assignments.
@timer@
expression e1,e2,e3,fn_ptr;
@@
-init_timer(&e1);
+setup_timer(&e1, fn_ptr, e2);
... when != fn_ptr = e3
-e1.function = fn_ptr;
-e1.data = e2;
Signed-off-by: Muhammad Falak R Wani
---
drivers/staging/rdma/ipath/ipath_init_chip.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rdma/ipath/ipath_init_chip.c
b/drivers/staging/rdma/ipath/ipath_init_chip.c
index 4aea99c..a5eea19 100644
--- a/drivers/staging/rdma/ipath/ipath_init_chip.c
+++ b/drivers/staging/rdma/ipath/ipath_init_chip.c
@@ -950,9 +950,8 @@ int ipath_init_chip(struct ipath_devdata *dd, int reinit)
* set up stats retrieval timer, even if we had errors
* in last portion of setup
*/
- init_timer(&dd->ipath_stats_timer);
- dd->ipath_stats_timer.function = ipath_get_faststats;
- dd->ipath_stats_timer.data = (unsigned long) dd;
+ setup_timer(&dd->ipath_stats_timer, ipath_get_faststats,
+ (unsigned long)dd);
/* every 5 seconds; */
dd->ipath_stats_timer.expires = jiffies + 5 * HZ;
/* takes ~16 seconds to overflow at full IB 4x bandwdith */
@@ -965,9 +964,8 @@ int ipath_init_chip(struct ipath_devdata *dd, int reinit)
ret = setup_sdma(dd);
/* Set up HoL state */
- init_timer(&dd->ipath_hol_timer);
- dd->ipath_hol_timer.function = ipath_hol_event;
- dd->ipath_hol_timer.data = (unsigned long)dd;
+ setup_timer(&dd->ipath_hol_timer, ipath_hol_event, (unsigned long)dd);
+
dd->ipath_hol_state = IPATH_HOL_UP;
done:
@@ -988,11 +986,9 @@ done:
* to an alternate if necessary and possible
*/
if (!reinit) {
- init_timer(&dd->ipath_intrchk_timer);
- dd->ipath_intrchk_timer.function =
- verify_interrupt;
- dd->ipath_intrchk_timer.data =
- (unsigned long) dd;
+ setup_timer(&dd->ipath_intrchk_timer,
+ verify_interrupt,
+ (unsigned long)dd);
}
dd->ipath_intrchk_timer.expires = jiffies + HZ/2;
add_timer(&dd->ipath_intrchk_timer);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] staging: rdma: ipath: Use setup_timer
Use the timer API function setup_timer instead of init_timer, removing
the structure field assignments.
@timer@
expression e1,e2,e3,fn_ptr;
@@
-init_timer(&e1);
+setup_timer(&e1, fn_ptr, e2);
... when != fn_ptr = e3
-e1.function = fn_ptr;
-e1.data = e2;
Signed-off-by: Muhammad Falak R Wani
---
drivers/staging/rdma/ipath/ipath_driver.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rdma/ipath/ipath_driver.c
b/drivers/staging/rdma/ipath/ipath_driver.c
index 46d9898..577704a 100644
--- a/drivers/staging/rdma/ipath/ipath_driver.c
+++ b/drivers/staging/rdma/ipath/ipath_driver.c
@@ -2307,10 +2307,9 @@ void ipath_set_led_override(struct ipath_devdata *dd,
unsigned int val)
*/
if (atomic_inc_return(&dd->ipath_led_override_timer_active) == 1) {
/* Need to start timer */
- init_timer(&dd->ipath_led_override_timer);
- dd->ipath_led_override_timer.function =
-ipath_run_led_override;
- dd->ipath_led_override_timer.data = (unsigned long) dd;
+ setup_timer(&dd->ipath_led_override_timer,
+ ipath_run_led_override, (unsigned long)dd);
+
dd->ipath_led_override_timer.expires = jiffies + 1;
add_timer(&dd->ipath_led_override_timer);
} else
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: most: hdm-usb: Use setup_timer
Use the timer API function setup_timer instead of init_timer, removing the structure field assignments. @timer@ expression e1,e2,e3,fn_ptr; @@ -init_timer(&e1); +setup_timer(&e1, fn_ptr, e2); ... when != fn_ptr = e3 -e1.function = fn_ptr; -e1.data = e2; Signed-off-by: Muhammad Falak R Wani --- drivers/staging/most/hdm-usb/hdm_usb.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/staging/most/hdm-usb/hdm_usb.c b/drivers/staging/most/hdm-usb/hdm_usb.c index 0bf38c4..2e07313 100644 --- a/drivers/staging/most/hdm-usb/hdm_usb.c +++ b/drivers/staging/most/hdm-usb/hdm_usb.c @@ -1235,11 +1235,10 @@ hdm_probe(struct usb_interface *interface, const struct usb_device_id *id) num_endpoints = usb_iface_desc->desc.bNumEndpoints; mutex_init(&mdev->io_mutex); INIT_WORK(&mdev->poll_work_obj, wq_netinfo); - init_timer(&mdev->link_stat_timer); + setup_timer(&mdev->link_stat_timer, link_stat_timer_handler, + (unsigned long)mdev); mdev->usb_device = usb_dev; - mdev->link_stat_timer.function = link_stat_timer_handler; - mdev->link_stat_timer.data = (unsigned long)mdev; mdev->link_stat_timer.expires = jiffies + (2 * HZ); mdev->iface.mod = hdm_usb_fops.owner; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.2 00/54] 4.2.5-stable review
On 10/23/2015 10:44 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.2.5 release. There are 54 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Oct 25 17:45:07 UTC 2015. Anything received after that time might be too late. Build results: total: 144 pass: 144 fail: 0 Qemu test results: total: 93 pass: 93 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Steal time accounting in KVM. Benchmark.
What I figured out. It happens in intersection of 3 features: *irq time accounting *stolen time accounting *linux guest with tickless idle only (not fully tickless) Looks like timer interrupts storm is happening during this benchmark (with 2:1 cpu overcommit). irq time accounting gets crazy. Even 'top' shows weird statistic: 50% hi, 50% st, ~0% user, spinning processes use ~0% cpu - that is not correct. Thanks. On Tue, Oct 20, 2015 at 5:24 PM, Alexey Makhalov wrote: > Yes, VM1 results are as before. > > Alexey > > On Tue, Oct 20, 2015 at 4:04 PM, Wanpeng Li wrote: >> On 10/21/15 4:05 AM, Alexey Makhalov wrote: >>> >>> 'echo NO_NONTASK_CAPACITY > /sys/kernel/debug/sched_features' in both >>> guests. >>> Results: >>> VM1: STA is disabled -- no changes, still little bit bellow expected 90% >>> VM2: STA is enabled -- result is changed, but still bad. Hard to say >>> better or worse. It prefers to stuck at quarters (100% 75% 50% 25%) >>> Output is attached. >> >> >> If the output in attachment is for VM2 only? >> >> Regards, >> Wanpeng Li -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/25] 3.14.56-stable review
On 10/23/2015 10:45 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.56 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Oct 25 17:45:45 UTC 2015. Anything received after that time might be too late. Build results: total: 127 pass: 127 fail: 0 Qemu test results: total: 80 pass: 80 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/17] 3.10.92-stable review
On 10/23/2015 10:44 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.92 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Oct 25 17:44:42 UTC 2015. Anything received after that time might be too late. Build results: total: 121 pass: 121 fail: 0 Qemu test results: total: 70 pass: 70 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: dts: Added syscon-reboot node for FSL's LS2085A SoC
Added sys-reboot node to the FSL's LS2085A SoC DT to leverage
the ARM-generic reboot mechanism for this SoC. This mechanism
is enabled through CONFIG_POWER_RESET_SYSCON.
Signed-off-by: J. German Rivera
---
arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
index e281ceb..6f82163 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
@@ -131,6 +131,18 @@
interrupts = <1 9 0x4>;
};
+ rst_ccsr: rstccsr@1E6 {
+ compatible = "syscon";
+ reg = <0x0 0x1E6 0x0 0x1>;
+ };
+
+ reboot@65024000 {
+ compatible ="syscon-reboot";
+ regmap = <&rst_ccsr>;
+ offset = <0x0>;
+ mask = <0x2>;
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] clk: ti816x: Add missing dmtimer clkdev entries
* Neil Armstrong [151022 02:19]:
> Add missing clkdev dmtimer related entries for dm816x.
> 32Khz and ext sources were missing.
>
> Cc: Brian Hutchinson
> Signed-off-by: Neil Armstrong
Tero should queue this one:
Acked-by: Tony Lindgren
> ---
> drivers/clk/ti/clk-816x.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/clk/ti/clk-816x.c b/drivers/clk/ti/clk-816x.c
> index 1dfad0c..2a5d84f 100644
> --- a/drivers/clk/ti/clk-816x.c
> +++ b/drivers/clk/ti/clk-816x.c
> @@ -20,6 +20,8 @@ static struct ti_dt_clk dm816x_clks[] = {
> DT_CLK(NULL, "sys_clkin", "sys_clkin_ck"),
> DT_CLK(NULL, "timer_sys_ck", "sys_clkin_ck"),
> DT_CLK(NULL, "sys_32k_ck", "sys_32k_ck"),
> + DT_CLK(NULL, "timer_32k_ck", "sysclk18_ck"),
> + DT_CLK(NULL, "timer_ext_ck", "tclkin_ck"),
> DT_CLK(NULL, "mpu_ck", "mpu_ck"),
> DT_CLK(NULL, "timer1_fck", "timer1_fck"),
> DT_CLK(NULL, "timer2_fck", "timer2_fck"),
> --
> 1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
hid-sony appears to be broken for some (new?) DualShock 4 controllers
I have a brand new DualShock 4 and the descriptor is a different size
than what the hid-sony driver expects. This causes the controller to not
work at all over wireless except for the trackpad. On USB it sort of
works but the motion sense does not. This affects kernels starting at
3.15 all the way to the current 4.3rc6.
In sony_report_fixup() it looks for a size of 467 for USB or 357 for
Bluetooth but my controller's descriptor size is 499 USB and 365 BT.
I changed the sizes and the controller seems to be fully functional now.
Is the descriptor size check actually even necessary? Don't all DS4's
require the modified descriptor table regardless? I don't know.
These are the changes I made against 4.3rc6:
---
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 661f94f..d93a6a8 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -1137,11 +1137,11 @@ static __u8 *sony_report_fixup(struct hid_device
*hdev, __u8 *rdesc,
* the gyroscope values to corresponding axes so we need a
* modified one.
*/
- if ((sc->quirks & DUALSHOCK4_CONTROLLER_USB) && *rsize == 467) {
+ if ((sc->quirks & DUALSHOCK4_CONTROLLER_USB) && (*rsize == 467
|| *rsize == 499)) {
hid_info(hdev, "Using modified Dualshock 4 report
descriptor with gyroscope axes\n");
rdesc = dualshock4_usb_rdesc;
*rsize = sizeof(dualshock4_usb_rdesc);
- } else if ((sc->quirks & DUALSHOCK4_CONTROLLER_BT) && *rsize ==
357) {
+ } else if ((sc->quirks & DUALSHOCK4_CONTROLLER_BT) && (*rsize ==
357 || *rsize == 365)) {
hid_info(hdev, "Using modified Dualshock 4 Bluetooth
report descriptor\n");
rdesc = dualshock4_bt_rdesc;
*rsize = sizeof(dualshock4_bt_rdesc);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data
Hi,
* Neil Armstrong [151022 02:19]:
> Add missing HWMOD_NO_IDLEST hwmod flag for entries no
> having omap4 clkctrl values.
Have you checked this is the case both in dm814x and dm816x TRM?
Also the documentation may not be complete FYI, might be also
worth checking the legacy TI kernel tree to be sure.
Regards,
Tony
> Cc: Brian Hutchinson
> Signed-off-by: Neil Armstrong
> ---
> arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> index b1288f5..6256052 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> @@ -144,6 +144,7 @@ static struct omap_hwmod dm81xx_l4_ls_hwmod = {
> .name = "l4_ls",
> .clkdm_name = "alwon_l3s_clkdm",
> .class = &l4_hwmod_class,
> + .flags = HWMOD_NO_IDLEST,
> };
>
> /*
> @@ -155,6 +156,7 @@ static struct omap_hwmod dm81xx_l4_hs_hwmod = {
> .name = "l4_hs",
> .clkdm_name = "alwon_l3_med_clkdm",
> .class = &l4_hwmod_class,
> + .flags = HWMOD_NO_IDLEST,
> };
>
> /* L3 slow -> L4 ls peripheral interface running at 125MHz */
> @@ -850,6 +852,7 @@ static struct omap_hwmod dm816x_emac0_hwmod = {
> .name = "emac0",
> .clkdm_name = "alwon_ethernet_clkdm",
> .class = &dm816x_emac_hwmod_class,
> + .flags = HWMOD_NO_IDLEST,
> };
>
> static struct omap_hwmod_ocp_if dm81xx_l4_hs__emac0 = {
> --
> 1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/31] perf record: Load eBPF object into kernel
发自我的 iPhone
> 在 2015年10月24日，上午12:58，Arnaldo Carvalho de Melo 写道：
>
> Em Wed, Oct 14, 2015 at 12:41:16PM +, Wang Nan escreveu:
>> This patch utilizes bpf_object__load() provided by libbpf to load all
>> objects into kernel.
>
> So, testing this, using that other proggie, I get;
>
> # perf record --event /tmp/foo.o sleep 1
> libbpf: load bpf program failed: Invalid argument
> libbpf: -- BEGIN DUMP LOG ---
> libbpf:
>
> libbpf: -- END LOG --
This means your kernel version and version section in your BPF object doesn't
match each other. Please try to pass a correct version code when compiling the
object. I think we should output something through error log so by -v we can see
the problem. I told Alexei about this problem once. Let me improve perf's
error message next week.
Thank you.
> libbpf: failed to load program 'fork=_do_fork'
> libbpf: failed to load object '/tmp/foo.o'
> event syntax error: '/tmp/foo.o'
> \___ Invalid argument: Are you root and runing a
> CONFIG_BPF_SYSCALL kernel?
>
> (add -v to see detail)
> Run 'perf list' for a list of valid events
>
> Usage: perf record [] []
> or: perf record [] -- []
>
> -e, --eventevent selector. use 'perf list' to list available
> events
>
> But:
>
> [root@felicio ~]# grep -i bpf /proc/kallsyms | wc -l
> 117
> [root@felicio ~]# grep -i sys_bpf /proc/kallsyms
> 811829d0 T SyS_bpf
> 811829d0 T sys_bpf
> [root@felicio ~]# uname -a
> Linux felicio.ghostprotocols.net 4.2.0 #1 SMP Mon Aug 31 12:25:38 BRT
> 2015 x86_64 x86_64 x86_64 GNU/Linux
> [root@felicio ~]#
>
>
> I'll try updating it to torvalds/master...
>
> For reference, that foo.o eBPF proggie was built with:
>
> [acme@felicio linux]$ cat ~/bin/hello-ebpf
> # Taken from 'perf test LLVM'
> # Thu Oct 22 12:07:26 BRT 2015
>
> export KERNEL_INC_OPTIONS="-nostdinc -isystem
> /usr/lib/gcc/x86_64-redhat-linux/4.8.3/include
> -I/home/acme/git/linux/arch/x86/include
> -Iarch/x86/include/generated/uapi -Iarch/x86/include/generated
> -I/home/acme/git/linux/include -Iinclude
> -I/home/acme/git/linux/arch/x86/include/uapi
> -Iarch/x86/include/generated/uapi -I/home/acme/git/linux/include/uapi
> -Iinclude/generated/uapi -include
> /home/acme/git/linux/include/linux/kconfig.h"
> export WORKING_DIR=/lib/modules/4.2.0/build
> export CLANG_SOURCE=-
> export CLANG_OPTIONS=-xc
>
> OBJ=/tmp/foo.o
> rm -f $OBJ
> echo '__attribute__((section("fork=_do_fork"), used)) int fork(void
> *ctx) {return 0;} char _license[] __attribute__((section("license"),
> used)) = "GPL";int _version __attribute__((section("version"), used)) =
> 0x40100;' | clang -D__KERNEL__ $CLANG_OPTIONS $KERNEL_INC_OPTIONS
> -Wno-unused-value -Wno-pointer-sign -working-directory $WORKING_DIR -c
> "$CLANG_SOURCE" -target bpf -O2 -o /tmp/foo.o && file $OBJ
>
> - Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf, tools, stat: Implement --metric-only mode
From: Andi Kleen
Add a new mode to only print metrics. Sometimes we don't care about
the raw values, just want the computed metrics. This allows more
compact printing, so with -I each sample is only a single line.
This also allows easier plotting and processing with other tools.
The main target is with using --topdown, but it also works with
-T and standard perf stat. A few metrics are not supported.
To avoiding having to hardcode all the metrics in the code it uses
a two pass approach: first compute dummy metrics and only
print the headers in the print_metric callback. Then use the callback
to print the actual values. There are some additional changes
in the stat printout code to handle all metrics being on a single line.
Example:
% perf stat -a -I 1000 --metric-only
1.000604977 frontend cycles idle backend cycles idle insn per
cycle stalled cycles per insn branch-misses of all branches
1.0006049770.76
2.35%
2.0009246800.72
2.34%
3.0011395920.76
2.57%
4.0013584520.73
2.44%
The output is fairly wide, but that's a trade off for the concise format.
Signed-off-by: Andi Kleen
---
tools/perf/Documentation/perf-stat.txt | 4 +
tools/perf/builtin-stat.c | 201 +++--
2 files changed, 196 insertions(+), 9 deletions(-)
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index 079b141..58296e7 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -132,6 +132,10 @@ Print count deltas every N milliseconds (minimum: 10ms)
The overhead percentage could be high in some cases, for instance with small,
sub 100ms intervals. Use with caution.
example: 'perf stat -I 1000 -e cycles -a sleep 5'
+--metric-only::
+Only print computed metrics. Print them in a single line.
+Don't show any raw values. Not supported with -A or --per-thread.
+
--per-socket::
Aggregate counts per processor socket for system-wide mode measurements. This
is a useful mode to detect imbalance between sockets. To enable this mode,
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 4042b97..af21afe 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -117,6 +117,7 @@ static bool sync_run
= false;
static unsigned intinitial_delay = 0;
static unsigned intunit_width = 4; /*
strlen("unit") */
static boolforever = false;
+static boolmetric_only = false;
static struct timespec ref_time;
static struct cpu_map *aggr_map;
static int (*aggr_get_id)(struct cpu_map *m, int cpu);
@@ -572,6 +573,99 @@ static void print_metric_csv(void *ctx,
fprintf(out, "%s%s%s", vals, csv_sep, unit);
}
+#define METRIC_ONLY_LEN 24
+
+/* Filter out some columns that don't work well in metrics only mode */
+
+static bool valid_only_metric(const char *unit)
+{
+ if (!unit)
+ return false;
+ if (strstr(unit, "/sec") ||
+ strstr(unit, "hz") ||
+ strstr(unit, "Hz") ||
+ strstr(unit, "CPUs utilized"))
+ return false;
+ return true;
+}
+
+static const char *fixunit(char *buf, struct perf_evsel *evsel,
+ const char *unit)
+{
+ if (!strncmp(unit, "of all", 6)) {
+ snprintf(buf, 1024, "%s %s", perf_evsel__name(evsel),
+unit);
+ return buf;
+ }
+ return unit;
+}
+
+static void print_metric_only(void *ctx, const char *color, const char *fmt,
+ const char *unit, double val)
+{
+ struct outstate *os = ctx;
+ FILE *out = os->fh;
+ int n;
+ char buf[1024];
+ unsigned mlen = METRIC_ONLY_LEN;
+
+ if (!valid_only_metric(unit))
+ return;
+ unit = fixunit(buf, os->evsel, unit);
+ if (color)
+ n = color_fprintf(out, color, fmt, val);
+ else
+ n = fprintf(out, fmt, val);
+ if (n > METRIC_ONLY_LEN)
+ n = METRIC_ONLY_LEN;
+ if (mlen < strlen(unit))
+ mlen = strlen(unit) + 1;
+ fprintf(out, "%*s", mlen - n, "");
+}
+
+static void print_metric_only_csv(void *ctx, const char *color __maybe_unused,
+ const char *fmt,
+ const char *unit, double val)
+{
+
Re: [PATCH v2] sunrpc: fix waitqueue_active without memory barrier in sunrpc
J. Bruce Fields wrote: > On Fri, Oct 23, 2015 at 04:14:10AM +, Kosuke Tatsukawa wrote: >> J. Bruce Fields wrote: >> > On Fri, Oct 16, 2015 at 02:28:10AM +, Kosuke Tatsukawa wrote: >> >> Tatsukawa Kosuke wrote: >> >> > J. Bruce Fields wrote: >> >> >> On Thu, Oct 15, 2015 at 11:44:20AM +, Kosuke Tatsukawa wrote: >> >> >>> Tatsukawa Kosuke wrote: >> >> >>> > J. Bruce Fields wrote: >> >> >>> >> Thanks for the detailed investigation. >> >> >>> >> >> >> >>> >> I think it would be worth adding a comment if that might help >> >> >>> >> someone >> >> >>> >> having to reinvestigate this again some day. >> >> >>> > >> >> >>> > It would be nice, but I find it difficult to write a comment in the >> >> >>> > sunrpc layer why a memory barrier isn't necessary, using the >> >> >>> > knowledge >> >> >>> > of how nfsd uses it, and the current implementation of the network >> >> >>> > code. >> >> >>> > >> >> >>> > Personally, I would prefer removing the call to waitqueue_active() >> >> >>> > which >> >> >>> > would make the memory barrier totally unnecessary at the cost of a >> >> >>> > spin_lock + spin_unlock by unconditionally calling >> >> >>> > wake_up_interruptible. >> >> >>> >> >> >>> On second thought, the callbacks will be called frequently from the >> >> >>> tcp >> >> >>> code, so it wouldn't be a good idea. >> >> >> >> >> >> So, I was even considering documenting it like this, if it's not >> >> >> overkill. >> >> >> >> >> >> Hmm... but if this is right, then we may as well ask why we're doing >> >> >> the >> >> >> wakeups at all. Might be educational to test the code with them >> >> >> removed. >> >> > >> >> > sk_write_space will be called in sock_wfree() with UDP/IP each time >> >> > kfree_skb() is called. With TCP/IP, sk_write_space is only called if >> >> > SOCK_NOSPACE has been set. >> >> > >> >> > sk_data_ready will be called in both tcp_rcv_established() for TCP/IP >> >> > and in sock_queue_rcv_skb() for UDP/IP. The latter lacks a memory >> >> > barrier with sk_data_ready called right after __skb_queue_tail(). >> >> > I think this hasn't caused any problems because sk_data_ready wasn't >> >> > used. >> >> >> >> Actually, svc_udp_data_ready() calls set_bit() which is an atomic >> >> operation. So there won't be a problem unless svsk is NULL. >> > >> > So is it true that every caller of these socket callbacks has adequate >> > memory barriers between the time the change is made visible and the time >> > the callback is called? >> > >> > If so, then there's nothing really specific about nfsd here. >> > >> > In that case maybe it's the networking code that use some documentation, >> > if it doesn't already? (Or maybe common helper functions for this >> > >> >if (waitqueue_active(wq)) >> >wake_up(wq) >> > >> > pattern?) >> >> Some of the other places defining these callback functions are using >> static inline bool wq_has_sleeper(struct socket_wq *wq) >> defined in include/net/sock.h >> >> The comment above the function explains that it was introduced for >> exactly this purpose. >> >> Even thought the argument variable uses the same name "wq", it has a >> different type from the wq used in svcsock.c (struct socket_wq * >> vs. wait_queue_head_t *). > > OK, thanks. So, I guess it still sounds like the code is OK as is, but > maybe my comment wasn't. Here's another attempt. Thank you. By now the patch looks completely different from my original patch, so I don't think I deserve to be mentioned in the Author line. > --b. > > commit b805ca58a81a > Author: Kosuke Tatsukawa > Date: Fri Oct 9 01:44:07 2015 + > > svcrpc: document lack of some memory barriers > > We're missing memory barriers in net/sunrpc/svcsock.c in some spots we'd > expect them. But it doesn't appear they're necessary in our case, and > this is likely a hot path--for now just document the odd behavior. > > I found this issue when I was looking through the linux source code > for places calling waitqueue_active() before wake_up*(), but without > preceding memory barriers, after sending a patch to fix a similar > issue in drivers/tty/n_tty.c (Details about the original issue can be > found here: https://lkml.org/lkml/2015/9/28/849). I should have used the stable link format to refer to the disucssion in LKML instead of the lkml.org URL. The stable link is http://lkml.kernel.org/r/17ec94b0a072c34b8dcf0d30ad16044a02871...@bpxm09gp.gisp.nec.co.jp > > Signed-off-by: Kosuke Tatsukawa > [bfie...@redhat.com,nfbr...@novell.com: document instead of adding > barriers] > Signed-off-by: J. Bruce Fields > > diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c > index 48923730722d..1f71eece04d3 100644 > --- a/net/sunrpc/svcsock.c > +++ b/net/sunrpc/svcsock.c > @@ -399,6 +399,31 @@ static int svc_sock_secure_port(struct svc_rqst *rqstp) > return svc_port_is_privileged(svc_addr(rqstp)); > } > > +static bool sunrp
Re: [PATCH 4.1 00/46] 4.1.12-stable review
On 10/23/2015 04:22 PM, Greg Kroah-Hartman wrote:
On Fri, Oct 23, 2015 at 02:34:56PM -0600, Shuah Khan wrote:
On 10/23/2015 11:45 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.1.12 release.
There are 46 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Oct 25 17:46:11 UTC 2015.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.1.12-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
I am seeing the following compile error (was seen in 4.2.4-rc1)
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from ./include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/capability.h:16,
from include/linux/capability.h:15,
from include/linux/sched.h:15,
from drivers/xen/preempt.c:12:
drivers/xen/preempt.c: In function ‘xen_maybe_preempt_hcall’:
drivers/xen/preempt.c:34:11: error: too few arguments to function
‘should_resched’
&& should_resched())) {
^
include/linux/compiler.h:164:42: note: in definition of macro ‘unlikely’
# define unlikely(x) __builtin_expect(!!(x), 0)
^
In file included from include/linux/preempt.h:18:0,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/uapi/linux/timex.h:56,
from include/linux/timex.h:56,
from include/linux/sched.h:19,
from drivers/xen/preempt.c:12:
./arch/x86/include/asm/preempt.h:93:29: note: declared here
static __always_inline bool should_resched(int preempt_offset)
^
scripts/Makefile.build:258: recipe for target 'drivers/xen/preempt.o' failed
make[2]: *** [drivers/xen/preempt.o] Error 1
make[2]: *** Waiting for unfinished jobs
scripts/Makefile.build:403: recipe for target 'drivers/xen' failed
make[1]: *** [drivers/xen] Error 2
Makefile:947: recipe for target 'drivers' failed
make: *** [drivers] Error 2
Also for powerpc:
arch/powerpc/kvm/book3s_hv.c: In function 'kvmppc_run_vcpu':
arch/powerpc/kvm/book3s_hv.c:2181:3: error: too few arguments to function
'should_resched'
[ Didn't we have that before ? ]
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] perf tools: Provide help for subset of options
From: Arnaldo Carvalho de Melo
Some tools have a lot of options, so, providing a way to show help just
for some of them may come handy:
$ perf report -h --tui
Usage: perf report []
--tui Use the TUI interface
$ perf report -h --tui --showcpuutilization -b -c
Usage: perf report []
-b, --branch-stackuse branch records for per branch histogram filling
-c, --comms
only consider symbols in these comms
--showcpuutilization
Show sample percentage for different cpu modes
--tui Use the TUI interface
$
Using it with perf bash completion is also handy, just make sure you
source the needed file:
$ . ~/git/linux/tools/perf/perf-completion.sh
Then press tab/tab after -- to see a list of options, put them after -h
and only the options chosen will have its help presented:
$ perf report -h --
--asm-raw --demangle-kernel --group
--kallsyms --pretty --stdio
--branch-history --disassembler-style --gtk
--max-stack--showcpuutilization --symbol-filter
--branch-stack --dsos --header
--mem-mode --show-info--symbols
--call-graph --dump-raw-trace --header-only
--modules --show-nr-samples --symfs
--children --exclude-other--hide-unresolved
--objdump --show-ref-call-graph --threads
--column-widths--fields --ignore-callees
--parent --show-total-period--tid
--comms--field-separator --input
--percentage --socket-filter--tui
--cpu --force--inverted
--percent-limit--sort --verbose
--demangle --full-source-path --itrace
--pid --source --vmlinux
$ perf report -h --socket-filter
Usage: perf report []
--socket-filter
only show processor socket that match with this filter
Suggested-by: Ingo Molnar
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: Brendan Gregg
Cc: Chandler Carruth
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-83mcdd3wj0379jcgea8w0...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-options.c | 42 -
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/tools/perf/util/parse-options.c b/tools/perf/util/parse-options.c
index fb26532d67c3..22c2806bda98 100644
--- a/tools/perf/util/parse-options.c
+++ b/tools/perf/util/parse-options.c
@@ -373,7 +373,8 @@ void parse_options_start(struct parse_opt_ctx_t *ctx,
}
static int usage_with_options_internal(const char * const *,
- const struct option *, int);
+ const struct option *, int,
+ struct parse_opt_ctx_t *);
int parse_options_step(struct parse_opt_ctx_t *ctx,
const struct option *options,
@@ -397,8 +398,9 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,
if (arg[1] != '-') {
ctx->opt = ++arg;
- if (internal_help && *ctx->opt == 'h')
- return usage_with_options_internal(usagestr,
options, 0);
+ if (internal_help && *ctx->opt == 'h') {
+ return usage_with_options_internal(usagestr,
options, 0, ctx);
+ }
switch (parse_short_opt(ctx, options)) {
case -1:
return parse_options_usage(usagestr, options,
arg, 1);
@@ -413,7 +415,7 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,
check_typos(arg, options);
while (ctx->opt) {
if (internal_help && *ctx->opt == 'h')
- return
usage_with_options_internal(usagestr, options, 0);
+ return
usage_with_options_internal(usagestr, options, 0, ctx);
arg = ctx->opt;
switch (parse_short_opt(ctx, options)) {
case -1:
@@ -446,9 +448,9 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,
arg += 2;
if (internal_help && !strcmp(arg, "help-all"))
- return usage_with_options_internal(usagestr, options,
1);
+ return usage_with_options_internal(usagestr, options,
1, ctx);
if (internal_help && !strcmp(arg, "help"))
- return usage_with_opt
[GIT PULL 0/2] perf/core new features
Hi Ingo, Please consider pulling, - Arnaldo The following changes since commit 80fcd45ee05b4ef05e61d37a5ffb70a67095a9f6: Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core (2015-10-23 10:25:57 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo for you to fetch changes up to 161d9041782b86c5493481566539bfc058ceeaff: perf tools: Provide help for subset of options (2015-10-23 21:50:50 -0300) perf/core improvements: New features: - Show ordered command line options when -h is used or when an unknown option is specified (Arnaldo Carvalho de Melo) - If options are passed after -h, show just its descriptions, not all options (Arnaldo Carvalho de Melo) Signed-off-by: Arnaldo Carvalho de Melo Arnaldo Carvalho de Melo (2): perf tools: Show tool command line options ordered perf tools: Provide help for subset of options tools/perf/util/parse-options.c | 90 - 1 file changed, 81 insertions(+), 9 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] perf tools: Show tool command line options ordered
From: Arnaldo Carvalho de Melo
When asking for a listing of the options, be it using -h or when an
unknown option is passed, order it by one-letter options, then the ones
having just long names.
Suggested-by: Ingo Molnar
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: Brendan Gregg
Cc: Chandler Carruth
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-41qh68t35n4ehrpsuazp1...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-options.c | 48 +
1 file changed, 48 insertions(+)
diff --git a/tools/perf/util/parse-options.c b/tools/perf/util/parse-options.c
index 8aa7922397a9..fb26532d67c3 100644
--- a/tools/perf/util/parse-options.c
+++ b/tools/perf/util/parse-options.c
@@ -2,6 +2,7 @@
#include "parse-options.h"
#include "cache.h"
#include "header.h"
+#include
#define OPT_SHORT 1
#define OPT_UNSET 2
@@ -642,9 +643,50 @@ static void print_option_help(const struct option *opts,
int full)
fprintf(stderr, "%*s%s\n", pad + USAGE_GAP, "", opts->help);
}
+static int option__cmp(const void *va, const void *vb)
+{
+ const struct option *a = va, *b = vb;
+ int sa = tolower(a->short_name), sb = tolower(b->short_name), ret;
+
+ if (sa == 0)
+ sa = 'z' + 1;
+ if (sb == 0)
+ sb = 'z' + 1;
+
+ ret = sa - sb;
+
+ if (ret == 0) {
+ const char *la = a->long_name ?: "",
+ *lb = b->long_name ?: "";
+ ret = strcmp(la, lb);
+ }
+
+ return ret;
+}
+
+static struct option *options__order(const struct option *opts)
+{
+ int nr_opts = 0;
+ const struct option *o = opts;
+ struct option *ordered;
+
+ for (o = opts; o->type != OPTION_END; o++)
+ ++nr_opts;
+
+ ordered = memdup(opts, sizeof(*o) * (nr_opts + 1));
+ if (ordered == NULL)
+ goto out;
+
+ qsort(ordered, nr_opts, sizeof(*o), option__cmp);
+out:
+ return ordered;
+}
+
int usage_with_options_internal(const char * const *usagestr,
const struct option *opts, int full)
{
+ struct option *ordered;
+
if (!usagestr)
return PARSE_OPT_HELP;
@@ -661,11 +703,17 @@ int usage_with_options_internal(const char * const
*usagestr,
if (opts->type != OPTION_GROUP)
fputc('\n', stderr);
+ ordered = options__order(opts);
+ if (ordered)
+ opts = ordered;
+
for ( ; opts->type != OPTION_END; opts++)
print_option_help(opts, full);
fputc('\n', stderr);
+ free(ordered);
+
return PARSE_OPT_HELP;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci: Update VPD size with correct length
On 10/23/2015 02:09 AM, Hannes Reinecke wrote:
PCI-2.2 VPD entries have a maximum size of 32k, but might actually
be smaller than that. To figure out the actual size one has to read
the VPD area until the 'end marker' is reached.
Trying to read VPD data beyond that marker results in 'interesting'
effects, from simple read errors to crashing the card.
This path modifies the attribute size to the avialable VPD size.
Signed-off-by: Hannes Reinecke
---
drivers/pci/access.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 6bc9b12..4f8208e 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -409,6 +409,34 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)
return ret;
}
+/**
+ * pci_vpd_size - determine actual size of Vital Product Data
+ * @dev: pci device struct
+ * @old_size: current assumed size, also maximum allowed size
+ *
+ */
+size_t
+pci_vpd_pci22_size(struct pci_dev *dev, size_t old_size)
+{
+ loff_t off = 0;
+ unsigned char header[1+2]; /* 1 byte tag, 2 bytes length */
+
+ while (off < old_size && pci_read_vpd(dev, off, 1, header)) {
+ if (header[0] == 0x78) /* End tag descriptor */
+ return off + 1;
+ if (header[0] & 0x80) {
+ /* Large Resource Data Type Tag */
+ if (pci_read_vpd(dev, off+1, 2, &header[1]) != 2)
+ return off + 1;
+ off += 3 + ((header[2] << 8) | header[1]);
+ } else {
+ /* Short Resource Data Type Tag */
+ off += 1 + (header[0] & 0x07);
+ }
+ }
+ return old_size;
+}
+
My understanding is that the end tag can have some data associated with
it such as a checksum. What you may want to look at doing is process
long tag and short tag bits first. Then you could do a mask and compare
after and if ((header[0] & ~0x7) == 0x78) then you return off + 1.
Also I was wondering if you have looked at the cxgb4 network driver?
They are using the vpd read/write calls to access their EEPROM and I
assume they are doing so outside the actual VPD fields.
- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/31] perf record: Load eBPF object into kernel
Em Fri, Oct 23, 2015 at 01:58:40PM -0300, Arnaldo Carvalho de Melo escreveu: > I'll try updating it to torvalds/master... Ok, still the same problem, this time with -vv, what does the following message mean? libbpf: don't need create maps for /tmp/foo.o Full output: [acme@felicio linux]$ sudo ~/bin/perf record -vv --event /tmp/foo.o sleep 1 libbpf: loading /tmp/foo.o libbpf: section .strtab, size 66, link 0, flags 0, type=3 libbpf: section .text, size 0, link 0, flags 6, type=1 libbpf: section .data, size 0, link 0, flags 3, type=1 libbpf: section .bss, size 0, link 0, flags 3, type=8 libbpf: section fork=_do_fork, size 16, link 0, flags 6, type=1 libbpf: found program fork=_do_fork libbpf: section license, size 4, link 0, flags 3, type=1 libbpf: license of /tmp/foo.o is GPL libbpf: section version, size 4, link 0, flags 3, type=1 libbpf: kernel version of /tmp/foo.o is 40100 libbpf: section .symtab, size 96, link 1, flags 0, type=2 bpf: config program 'fork=_do_fork' symbol:_do_fork file:(null) line:0 offset:0 return:0 lazy:(null) bpf: config 'fork=_do_fork' is ok Blacklist: 0x81016f10-0x81016f50, do_device_not_available Blacklist: 0x810171f0-0x810173e0, do_debug Blacklist: 0x81016eb0-0x81016f10, fixup_bad_iret Blacklist: 0x81016bd0-0x81016c00, sync_regs Blacklist: 0x81016f50-0x810170a0, do_int3 Blacklist: 0x810170a0-0x810171f0, do_general_protection Blacklist: 0x81016c00-0x81016d40, do_trap Blacklist: 0x81019a10-0x81019af0, __die Blacklist: 0x810198e0-0x810199b0, oops_end Blacklist: 0x81019830-0x810198e0, oops_begin Blacklist: 0x8101a770-0x8101a8c0, do_nmi Blacklist: 0x8101a680-0x8101a770, default_do_nmi Blacklist: 0x8101a560-0x8101a5f0, unknown_nmi_error Blacklist: 0x8101a5f0-0x8101a680, io_check_error Blacklist: 0x8101a4e0-0x8101a560, pci_serr_error Blacklist: 0x8101a0d0-0x8101a1f0, nmi_handle Blacklist: 0x81027a90-0x81027b10, debug_stack_reset Blacklist: 0x81027a40-0x81027a90, debug_stack_set_zero Blacklist: 0x81027a00-0x81027a40, is_debug_stack Blacklist: 0x8102b400-0x8102b440, perf_event_nmi_handler Blacklist: 0x8104b020-0x8104b060, perf_ibs_nmi_handler Blacklist: 0x810526a0-0x810526c0, arch_trigger_all_cpu_backtrace_handler Blacklist: 0x8105b090-0x8105b180, longjmp_break_handler Blacklist: 0x8105ae21-0x8105ae30, jprobe_return_end Blacklist: 0x8105ae00-0x8105ae21, jprobe_return Blacklist: 0x8105ae70-0x8105af10, setjmp_pre_handler Blacklist: 0x8105b040-0x8105b090, kprobe_exceptions_notify Blacklist: 0x8105af10-0x8105b040, kprobe_fault_handler Blacklist: 0x8105b8f0-0x8105b9c0, kprobe_debug_handler Blacklist: 0x8105b720-0x8105b8f0, resume_execution Blacklist: 0x8105b180-0x8105b380, trampoline_handler Blacklist: 0x8105ada9-0x8105ae00, kretprobe_trampoline Blacklist: 0x8105ada0-0x8105ada9, kretprobe_trampoline_holder Blacklist: 0x8105b5c0-0x8105b720, kprobe_int3_handler Blacklist: 0x8105b520-0x8105b5c0, reenter_kprobe Blacklist: 0x8105b380-0x8105b520, setup_singlestep Blacklist: 0x8105ad80-0x8105ada0, arch_prepare_kretprobe Blacklist: 0x8105ae30-0x8105ae70, skip_prefixes Blacklist: 0x8105ad60-0x8105ad80, synthesize_relcall Blacklist: 0x8105ad40-0x8105ad60, synthesize_reljump Blacklist: 0x8105c0c0-0x8105c110, setup_detour_execution Blacklist: 0x8105c020-0x8105c0c0, optimized_callback Blacklist: 0x8105c860-0x8105c970, kprobe_ftrace_handler Blacklist: 0x8105c970-0x8105c9c0, skip_singlestep Blacklist: 0x8105fec0-0x8105ff70, do_async_page_fault Blacklist: 0x8105f820-0x8105f850, kvm_read_and_reset_pf_reason Blacklist: 0x810607a0-0x810607b0, native_load_idt Blacklist: 0x81060a30-0x81060a80, native_set_debugreg Blacklist: 0x81060a80-0x81060ad0, native_get_debugreg Blacklist: 0x81064f00-0x81064ff0, trace_do_page_fault Blacklist: 0x81064e80-0x81064f00, do_page_fault Blacklist: 0x81064a90-0x81064e80, __do_page_fault Blacklist: 0x81064900-0x81064a90, spurious_fault Blacklist: 0x81063e50-0x810640d0, vmalloc_fault Blacklist: 0x810bb8d0-0x810bb930, notify_die Blacklist: 0x810bb7f0-0x810bb810, atomic_notifier_call_chain Blacklist: 0x810bb7d0-0x810bb7f0, __atomic_notifier_call_chain Blacklist: 0x810bb760-0xfff
lseek(fd, 0, SEEK_CUR) returns unexpected result for O_APPEND file on linux 2.6.32-431.29.2
Below is a description of a simple test case that causes lseek(fd, 0,
SEEK_CUR) to return an unexpectedly small result on one of my
computers, with linux 2.6.32-431.29.2, but none of the others. I'm
posting it on the off chance that this is (or was) a kernel bug, and
not some problem on my end.
The program below creates a file containing the string
"01234", closes it, then opens it for appending, writes "a"
to it (which should be appended, creating "01234a"), truncates
it to the current position in the file (the end, and hence a no-op),
and finally writes "b", resulting in "01234ab".
This is indeed the result on most systems I've run it on, for example
$ uname -a Linux regulus.uio.no 2.6.32-573.7.1.el6.x86_64 #1 SMP Thu
Sep 10 13:42:16 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
$ gcc -o append_bug{,.c}
$ ./append_bug; cat foo.txt; echo
$01234ab
However, on one system with linux 2.6.32-431.29.2, the program gives
unexpected results because lseek returns 1 rather than the expected 6,
resulting in the output "0b".
$ uname -a Linux nekkar.uio.no 2.6.32-431.29.2.el6.x86_64 #1 SMP Sun
Jul 27 15:55:46 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
$ gcc -o append_bug{,.c}
$ ./append_bug; cat foo.txt; echo
0b
$ cat append_bug.c
#include
#include
#include
#include
int main(int argc, char ** argv)
{
int f; off_t n;
f = open("foo.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666);
write(f, "01234", 5);
close(f);
f = open("foo.txt", O_WRONLY|O_APPEND);
write(f, "a", 1);
n = lseek(f, 0, SEEK_CUR);
ftruncate(f, n);
write(f, "b", 1);
close(f);
}
The version of gcc used was the rather old 4.4.7, but the compiler
version appears to be irrelevant - the executable from the
computer that exhibits the behavior does not do so when run
on e.g. my linux 2.6.32-573.7.1 computer. I reproduce the same
problem with icc. It occurs uniformly across all the 2.6.32-431.29.2
computers I have access to.
Could this be a kernel bug that was fixed between these
linux versions? If so, my google and lkml searches have not
turned up any mention of it (thought I did find patch that mentions
a marginally similar-sounding issue (https://lkml.org/lkml/2008/11/10/369).
The behavior was originally discovered when a colleague of mine
experienced that using shell redirection to append stdout of a fortran
program compiled with ifort resulted in the output file being truncated.
E.g. fortprog >> foo.txt would truncate rather than appending.
The strange write, lseek, ftruncate, write procedure used in
this program is a replica of ifort behavior, which only results in
incorrect results in the presence of this bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] net: thunderx: Support pass-2 revision hardware.
From: David Daney With the availability of a new revision of the ThunderX NIC hardware a few changes to the driver are required. With these, the driver works on all currently available hardware revisions. David Daney (1): net: thunderx: Rewrite silicon revision tests. Sunil Goutham (2): net: thunderx: Remove PF soft reset. net: thunderx: Fix incorrect subsystem devid of VF on pass2 silicon Thanneeru Srinivasulu (1): net: thunderx: Incorporate pass2 silicon CPI index configuration changes drivers/net/ethernet/cavium/thunder/nic_main.c | 42 drivers/net/ethernet/cavium/thunder/nic_reg.h| 4 +++ drivers/net/ethernet/cavium/thunder/nicvf_main.c | 2 +- 3 files changed, 34 insertions(+), 14 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] net: thunderx: Rewrite silicon revision tests.
From: David Daney
The test for pass-1 silicon was incorrect, it should be for all
revisions less than 8. Also the revision is already present in the
pci_dev, so there is no need to read and keep a private copy.
Remove rev_id and code to read it from struct nicpf. Create new
static inline function pass1_silicon() to be used to testing the
silicon version. Use pass1_silicon() for revision checks, this will
be more widely used in follow on patches.
Signed-off-by: David Daney
---
drivers/net/ethernet/cavium/thunder/nic_main.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index d6e3219..52e1acb 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -22,7 +22,6 @@
struct nicpf {
struct pci_dev *pdev;
- u8 rev_id;
u8 node;
unsigned intflags;
u8 num_vf_en; /* No of VF enabled */
@@ -54,6 +53,11 @@ struct nicpf {
boolirq_allocated[NIC_PF_MSIX_VECTORS];
};
+static inline bool pass1_silicon(struct nicpf *nic)
+{
+ return nic->pdev->revision < 8;
+}
+
/* Supported devices */
static const struct pci_device_id nic_id_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_CAVIUM, PCI_DEVICE_ID_THUNDER_NIC_PF) },
@@ -117,7 +121,7 @@ static void nic_send_msg_to_vf(struct nicpf *nic, int vf,
union nic_mbx *mbx)
* when PF writes to MBOX(1), in next revisions when
* PF writes to MBOX(0)
*/
- if (nic->rev_id == 0) {
+ if (pass1_silicon(nic)) {
/* see the comment for nic_reg_write()/nic_reg_read()
* functions above
*/
@@ -998,8 +1002,6 @@ static int nic_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
goto err_release_regions;
}
- pci_read_config_byte(pdev, PCI_REVISION_ID, &nic->rev_id);
-
nic->node = nic_get_node_id(pdev);
nic_set_lmac_vf_mapping(nic);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] net: thunderx: Incorporate pass2 silicon CPI index configuration changes
From: Thanneeru Srinivasulu
Add support for ThunderX pass2 CPI and MPI configuration changes.
MPI_ALG is not enabled i.e MCAM parsing is disabled.
Signed-off-by: Thanneeru Srinivasulu
Signed-off-by: Sunil Goutham
Signed-off-by: David Daney
---
drivers/net/ethernet/cavium/thunder/nic_main.c | 29 --
drivers/net/ethernet/cavium/thunder/nic_reg.h | 4
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 52e1acb..c561fdc 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -43,6 +43,7 @@ struct nicpf {
u8 duplex[MAX_LMAC];
u32 speed[MAX_LMAC];
u16 cpi_base[MAX_NUM_VFS_SUPPORTED];
+ u16 rssi_base[MAX_NUM_VFS_SUPPORTED];
u16 rss_ind_tbl_size;
boolmbx_lock[MAX_NUM_VFS_SUPPORTED];
@@ -396,8 +397,18 @@ static void nic_config_cpi(struct nicpf *nic, struct
cpi_cfg_msg *cfg)
padd = cpi % 8; /* 3 bits CS out of 6bits DSCP */
/* Leave RSS_SIZE as '0' to disable RSS */
- nic_reg_write(nic, NIC_PF_CPI_0_2047_CFG | (cpi << 3),
- (vnic << 24) | (padd << 16) | (rssi_base + rssi));
+ if (pass1_silicon(nic)) {
+ nic_reg_write(nic, NIC_PF_CPI_0_2047_CFG | (cpi << 3),
+ (vnic << 24) | (padd << 16) |
+ (rssi_base + rssi));
+ } else {
+ /* Set MPI_ALG to '0' to disable MCAM parsing */
+ nic_reg_write(nic, NIC_PF_CPI_0_2047_CFG | (cpi << 3),
+ (padd << 16));
+ /* MPI index is same as CPI if MPI_ALG is not enabled */
+ nic_reg_write(nic, NIC_PF_MPI_0_2047_CFG | (cpi << 3),
+ (vnic << 24) | (rssi_base + rssi));
+ }
if ((rssi + 1) >= cfg->rq_cnt)
continue;
@@ -410,6 +421,7 @@ static void nic_config_cpi(struct nicpf *nic, struct
cpi_cfg_msg *cfg)
rssi = ((cpi - cpi_base) & 0x38) >> 3;
}
nic->cpi_base[cfg->vf_id] = cpi_base;
+ nic->rssi_base[cfg->vf_id] = rssi_base;
}
/* Responsds to VF with its RSS indirection table size */
@@ -435,10 +447,9 @@ static void nic_config_rss(struct nicpf *nic, struct
rss_cfg_msg *cfg)
{
u8 qset, idx = 0;
u64 cpi_cfg, cpi_base, rssi_base, rssi;
+ u64 idx_addr;
- cpi_base = nic->cpi_base[cfg->vf_id];
- cpi_cfg = nic_reg_read(nic, NIC_PF_CPI_0_2047_CFG | (cpi_base << 3));
- rssi_base = (cpi_cfg & 0x0FFF) + cfg->tbl_offset;
+ rssi_base = nic->rssi_base[cfg->vf_id] + cfg->tbl_offset;
rssi = rssi_base;
qset = cfg->vf_id;
@@ -455,9 +466,15 @@ static void nic_config_rss(struct nicpf *nic, struct
rss_cfg_msg *cfg)
idx++;
}
+ cpi_base = nic->cpi_base[cfg->vf_id];
+ if (pass1_silicon(nic))
+ idx_addr = NIC_PF_CPI_0_2047_CFG;
+ else
+ idx_addr = NIC_PF_MPI_0_2047_CFG;
+ cpi_cfg = nic_reg_read(nic, idx_addr | (cpi_base << 3));
cpi_cfg &= ~(0xFULL << 20);
cpi_cfg |= (cfg->hash_bits << 20);
- nic_reg_write(nic, NIC_PF_CPI_0_2047_CFG | (cpi_base << 3), cpi_cfg);
+ nic_reg_write(nic, idx_addr | (cpi_base << 3), cpi_cfg);
}
/* 4 level transmit side scheduler configutation
diff --git a/drivers/net/ethernet/cavium/thunder/nic_reg.h
b/drivers/net/ethernet/cavium/thunder/nic_reg.h
index 58197bb..dd536be 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_reg.h
+++ b/drivers/net/ethernet/cavium/thunder/nic_reg.h
@@ -85,7 +85,11 @@
#define NIC_PF_ECC3_DBE_INT_W1S (0x2708)
#define NIC_PF_ECC3_DBE_ENA_W1C (0x2710)
#define NIC_PF_ECC3_DBE_ENA_W1S (0x2718)
+#define NIC_PF_MCAM_0_191_ENA(0x10)
+#define NIC_PF_MCAM_0_191_M_0_5_DATA (0x11)
+#define NIC_PF_MCAM_CTRL (0x12)
#define NIC_PF_CPI_0_2047_CFG(0x20)
+#define NIC_PF_MPI_0_2047_CFG(0x21)
#define NIC_PF_RSSI_0_4097_RQ(0x22)
#define NIC_PF_LMAC_0_7_CFG (0x24)
#define NIC_PF_LMAC_0_7_SW_XOFF (0x242000)
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] net: thunderx: Fix incorrect subsystem devid of VF on pass2 silicon
From: Sunil Goutham
Signed-off-by: Sunil Goutham
Signed-off-by: David Daney
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index b63e579..a937772 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -29,7 +29,7 @@
static const struct pci_device_id nicvf_id_table[] = {
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_CAVIUM,
PCI_DEVICE_ID_THUNDER_NIC_VF,
-PCI_VENDOR_ID_CAVIUM, 0xA11E) },
+PCI_VENDOR_ID_CAVIUM, 0xA134) },
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_CAVIUM,
PCI_DEVICE_ID_THUNDER_PASS1_NIC_VF,
PCI_VENDOR_ID_CAVIUM, 0xA11E) },
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] net: thunderx: Remove PF soft reset.
From: Sunil Goutham
In some silicon revisions, the soft reset clobbers PCI config space,
so quit doing the reset.
Signed-off-by: Sunil Goutham
Signed-off-by: David Daney
---
drivers/net/ethernet/cavium/thunder/nic_main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index b3a5947..d6e3219 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -305,9 +305,6 @@ static void nic_init_hw(struct nicpf *nic)
{
int i;
- /* Reset NIC, in case the driver is repeatedly inserted and removed */
- nic_reg_write(nic, NIC_PF_SOFT_RESET, 1);
-
/* Enable NIC HW block */
nic_reg_write(nic, NIC_PF_CFG, 0x3);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
On 10/23/2015 06:18 PM, Mark Brown wrote:
On Fri, Oct 23, 2015 at 07:46:39AM -0500, Andrew F. Davis wrote:
I know just because other drivers do it doesn't mean it's a good idea,
but this is not new for MFDs and it is done in other regulators as well
(mt6397, tps659038, qcom,spmi, etc..).
mt6397 doesn't do this, it doesn't have a compatible string at all (it's
doing what I'm recommending that you do). The SPMI devices are
standalone devices, their parent device is actually functioning as a bus
controller here (it's really a microcontroller inside the SoC). The
Palmas is part of how we realised this was a problem.
mt6397: Documentation/devicetree/bindings/mfd/mt6397.txt
Doing exactly what I'm doing,
pmic {
compatible = "mediatek,mt6397";
codec: mt6397codec {
compatible = "mediatek,mt6397-codec";
};
regulators {
compatible = "mediatek,mt6397-regulator";
buck_vpca15 {
The Palmas is a great example of why this is a good idea, there are
so many spins on this common base, and look how we can re-use sub-nodes:
tps659038: tps659038@58 {
compatible = "ti,tps659038";
reg = <0x58>;
...
tps659038_pmic {
compatible = "ti,tps659038-pmic";
...
};
tps659038_rtc: tps659038_rtc {
compatible = "ti,palmas-rtc";
...
};
tps659038_pwr_button: tps659038_pwr_button {
compatible = "ti,palmas-pwrbutton";
...
};
tps659038_gpio: tps659038_gpio {
compatible = "ti,palmas-gpio";
...
};
};
(from am57xx-beagle-x15.dts)
looks like only the "ti,tps659038-pmic" node needed re-made without
re-making the whole driver.
It seems like this is describing how Linux
loads drivers not how the hardware is constructed but DT should describe
the hardware.
While I agree to a point, if we follow this to its logical conclusion we
would end up with one compatible binding per SoC and be basically back to
board files. We need some granularity, just finding out where is the issue,
The fact that the SoC DT is not distinct from the board DT is actually
one of the problems with the way we're using DT at the minute, it means
that DTBs are much less stable than they should be since we can enhance
support for SoCs but DTBs need regenerating to take advantage of it. It
would be much better if the boards just referenced the SoC they use and
pulled in a separate definition of the SoC (DT overlays will make it
much more tractable to implement that if someone has time...).
I figured this can already be done by keeping the SoC stuff in dtsi files?
Anyway DT seems to have a lot of use issues with how it is being used, but
I'm probably not a person with enough free time for fixing that.. :|
I would say that as these devices belong to different subsystems and are
almost completely independent there should be no problem with having their
own compatible matched hardware sub-node.
All it's adding is more typing for users.
Well I have to match the sub-devices on something, it's ether the node name
or the compatible string, so they might have to get used to typing :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/9] perf, tools: Support metrics in --per-core/socket mode
From: Andi Kleen
Enable metrics printing in --per-core / --per-socket mode. We need
to save the shadow metrics in a unique place. Always use the first
CPU in the aggregation. Then use the same CPU to retrieve the
shadow value later.
Example output:
% perf stat --per-core -a ./BC1s
Performance counter stats for 'system wide':
S0-C0 22966.020381 task-clock (msec) #2.004
CPUs utilized(100.00%)
S0-C0 2 49 context-switches #0.017
K/sec(100.00%)
S0-C0 2 4 cpu-migrations#0.001
K/sec(100.00%)
S0-C0 2467 page-faults #0.157
K/sec
S0-C0 2 4,599,061,773 cycles#1.551
GHz (100.00%)
S0-C0 2 9,755,886,883 instructions #2.12
insn per cycle (100.00%)
S0-C0 2 1,906,272,125 branches # 642.704
M/sec(100.00%)
S0-C0 2 81,180,867 branch-misses #4.26%
of all branches
S0-C1 22965.995373 task-clock (msec) #2.003
CPUs utilized(100.00%)
S0-C1 2 62 context-switches #0.021
K/sec(100.00%)
S0-C1 2 8 cpu-migrations#0.003
K/sec(100.00%)
S0-C1 2281 page-faults #0.095
K/sec
S0-C1 2 6,347,290 cycles#0.002
GHz (100.00%)
S0-C1 2 4,654,156 instructions #0.73
insn per cycle (100.00%)
S0-C1 2947,121 branches #0.319
M/sec(100.00%)
S0-C1 2 37,322 branch-misses #3.94%
of all branches
1.480409747 seconds time elapsed
v2: Rebase to older patches
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 58 +--
1 file changed, 51 insertions(+), 7 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 97ffe7e..4042b97 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -490,6 +490,8 @@ struct outstate {
const char *prefix;
int nfields;
u64 run, ena;
+ int id, nr;
+ struct perf_evsel *evsel;
};
#define METRIC_LEN 35
@@ -500,12 +502,9 @@ static void new_line_std(void *ctx)
fputc('\n', os->fh);
fputs(os->prefix, os->fh);
+ aggr_printout(os->evsel, os->id, os->nr);
if (stat_config.aggr_mode == AGGR_NONE)
fprintf(os->fh, "");
- if (stat_config.aggr_mode == AGGR_CORE)
- fprintf(os->fh, " ");
- if (stat_config.aggr_mode == AGGR_SOCKET)
- fprintf(os->fh, "");
fprintf(os->fh, " ");
}
@@ -537,6 +536,7 @@ static void new_line_csv(void *ctx)
fputc('\n', os->fh);
if (os->prefix)
fprintf(os->fh, "%s%s", os->prefix, csv_sep);
+ aggr_printout(os->evsel, os->id, os->nr);
for (i = 0; i < os->nfields; i++)
fputs(csv_sep, os->fh);
}
@@ -600,6 +600,22 @@ static void nsec_printout(int id, int nr, struct
perf_evsel *evsel, double avg)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
}
+static int first_shadow_cpu(struct perf_evsel *evsel, int id)
+{
+ int i;
+
+ if (aggr_get_id == NULL)
+ return 0;
+
+ for (i = 0; i < perf_evsel__nr_cpus(evsel); i++) {
+ int cpu2 = perf_evsel__cpus(evsel)->map[i];
+
+ if (aggr_get_id(evsel_list->cpus, cpu2) == id)
+ return cpu2;
+ }
+ return 0;
+}
+
static void abs_printout(int id, int nr, struct perf_evsel *evsel, double avg)
{
FILE *output = stat_config.output;
@@ -636,7 +652,10 @@ static void printout(int id, int nr, struct perf_evsel
*counter, double uval,
struct perf_stat_output_ctx out;
struct outstate os = {
.fh = stat_config.output,
- .prefix = prefix ? prefix : ""
+ .prefix = prefix ? prefix : "",
+ .id = id,
+ .nr = nr,
+ .evsel = counter,
};
print_metric_t pm = print_metric_std;
void (*nl)(void *);
@@ -697,9 +716,8 @@ static void printout(int id, int nr, struct perf_evsel
*counter, double uval,
perf_stat__print_shadow_stats(counter, uval,
stat_config.aggr_mode == AGGR_GLOBAL ? 0 :
- cpu_map__id_to_cpu(id),
+
perf, tools: Refactor and support interval and CSV metrics v5
I hope this version is acceptable now. [v4: Addressed all review feedback.] [v3: Addressed all review feedback. Update manpage for CSV. Various changes (see individual patches). Remove some more redundant code in printout callers.] [v2: Addressed (near) all review feedback. No manpage updates so far. Add support for --per-core metrics. Various cleanups.] [v3: Everything compiles again. Some more cleanups.] [v4: Split up abstract metrics patch into two. Fix bug with earlier patch already enabling metrics for CSV/interval. Minor cleanups. Man page is included] [v5: Fix mainly bisect problems. No regressions introduced by one patch and fixed again later. Some minor fixes in addition] Currently perf stat does not support printing computed metrics for interval (-I xxx) or CSV (-x,) mode. For example IPC or TSX metrics over time are quite useful to know. This patch implements them. The main obstacle was that the metrics printing was all open coded all over the metrics computation code. The second patch refactors the metrics printing to work through call backs that can be more easily changed. This also cleans up the metrics printing significantly. Then based on that it implements metrics printing for CSV and interval mode. Example output: % perf stat -I1000 -a sleep 1 # time counts unit eventsmetric multiplex 1.001301370 12020.049593 task-clock (msec) (100.00%) 1.001301370 3,952 context-switches #0.329 K/sec(100.00%) 1.001301370 69 cpu-migrations#0.006 K/sec(100.00%) 1.001301370 76 page-faults #0.006 K/sec 1.001301370386,582,789 cycles#0.032 GHz (100.00%) 1.001301370716,441,544 stalled-cycles-frontend # 185.33% frontend cycles idle (100.00%) 1.001301370 stalled-cycles-backend 1.001301370101,751,678 instructions #0.26 insn per cycle 1.001301370 #7.04 stalled cycles per insn (100.00%) 1.001301370 20,914,692 branches #1.740 M/sec(100.00%) 1.001301370 1,943,630 branch-misses #9.29% of all branches CSV mode % perf stat -x, -I1000 -a sleep 1 1.000852081,12016.143006,,task-clock 1.000852081,4457,,context-switches,12015168277,100.00,0.371,K/sec 1.000852081,50,,cpu-migrations,12014024424,100.00,0.004,K/sec 1.000852081,76,,page-faults,12013076716,100.00,0.006,K/sec 1.000852081,515854373,,cycles,12011235336,100.00,0.043,GHz 1.000852081,1030742150,,stalled-cycles-frontend,12010984057,100.00,199.81,frontend cycles idle 1.000852081,,,stalled-cycles-backend,0,100.00 1.000852081,116782495,,instructions,12011130729,100.00,0.23,insn per cycle 1.00085208112011130729,100.00,8.83,stalled cycles per insn 1.000852081,23748237,,branches,12010745125,100.00,1.976,M/sec 1.000852081,1976560,,branch-misses,12010501884,100.00,8.32,of all branches Available in git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc-2.6 perf/stat-metrics-9 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] perf, tools, stat: Document CSV format in manpage
From: Andi Kleen With all the recently added fields in the perf stat CSV output we should finally document them in the man page. Do this here. Signed-off-by: Andi Kleen --- tools/perf/Documentation/perf-stat.txt | 19 +++ 1 file changed, 19 insertions(+) diff --git a/tools/perf/Documentation/perf-stat.txt b/tools/perf/Documentation/perf-stat.txt index 4e074a6..079b141 100644 --- a/tools/perf/Documentation/perf-stat.txt +++ b/tools/perf/Documentation/perf-stat.txt @@ -177,6 +177,25 @@ $ perf stat -- make -j Wall-clock time elapsed: 719.554352 msecs +CSV FORMAT +-- + +With -x, perf stat is able to output a not-quite-CSV format output +(commas in the output are not put into "") + +The fields are in this order: + + - optional usec time stamp in fractions of second (with -I xxx) + - unit of the counter value or empty + - event name + - counter value + - run time of counter + - percentage of measurement time the counter was running + - optional metric value + - optional unit of metric + +Additional metrics may be printed with all earlier fields being empty. + SEE ALSO linkperf:perf-top[1], linkperf:perf-list[1] -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] perf, tools, stat: Implement CSV metrics output
From: Andi Kleen
Now support CSV output for metrics. With the new output callbacks
this is relatively straight forward by creating new callbacks.
The new line callback needs to know the number of fields to skip them
correctly
v2: Split out function argument changes
v3: Reenable metrics for real.
v4: Fix wrong hunk from refactoring.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 67 +--
1 file changed, 65 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 1d77520..73b5cea 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -488,6 +488,8 @@ static void aggr_printout(struct perf_evsel *evsel, int id,
int nr)
struct outstate {
FILE *fh;
const char *prefix;
+ int nfields;
+ u64 run, ena;
};
#define METRIC_LEN 35
@@ -527,6 +529,49 @@ static void print_metric_std(void *ctx, const char *color,
const char *fmt,
fprintf(out, " %-*s", METRIC_LEN - n - 1, unit);
}
+static void new_line_csv(void *ctx)
+{
+ struct outstate *os = ctx;
+ int i;
+
+ fputc('\n', os->fh);
+ if (os->prefix)
+ fprintf(os->fh, "%s%s", os->prefix, csv_sep);
+ for (i = 0; i < os->nfields; i++)
+ fputs(csv_sep, os->fh);
+}
+
+static void print_metric_csv(void *ctx,
+const char *color __maybe_unused,
+const char *fmt, const char *unit, double val)
+{
+ struct outstate *os = ctx;
+ FILE *out = os->fh;
+ char buf[64], *vals, *ends;
+
+ if (unit == NULL) {
+ fprintf(out, "%s%s%s%s", csv_sep, csv_sep, csv_sep, csv_sep);
+ return;
+ }
+ fprintf(out, "%s%" PRIu64 "%s%.2f%s",
+ csv_sep,
+ os->run,
+ csv_sep,
+ os->ena ? 100.0 * os->run / os->ena : 100.0,
+ csv_sep);
+ snprintf(buf, sizeof(buf), fmt, val);
+ vals = buf;
+ while (isspace(*vals))
+ vals++;
+ ends = vals;
+ while (isdigit(*ends) || *ends == '.')
+ ends++;
+ *ends = 0;
+ while (isspace(*unit))
+ unit++;
+ fprintf(out, "%s%s%s", vals, csv_sep, unit);
+}
+
static void nsec_printout(int id, int nr, struct perf_evsel *evsel, double avg)
{
FILE *output = stat_config.output;
@@ -598,6 +643,25 @@ static void printout(int id, int nr, struct perf_evsel
*counter, double uval,
nl = new_line_std;
+ if (csv_output) {
+ static int aggr_fields[] = {
+ [AGGR_GLOBAL] = 0,
+ [AGGR_THREAD] = 1,
+ [AGGR_NONE] = 1,
+ [AGGR_SOCKET] = 2,
+ [AGGR_CORE] = 2,
+ };
+
+ pm = print_metric_csv;
+ nl = new_line_csv;
+ os.nfields = 1;
+ os.nfields += aggr_fields[stat_config.aggr_mode];
+ if (counter->cgrp)
+ os.nfields++;
+ os.run = run;
+ os.ena = ena;
+ }
+
if (nsec_counter(counter))
nsec_printout(id, nr, counter, uval);
else
@@ -607,8 +671,7 @@ static void printout(int id, int nr, struct perf_evsel
*counter, double uval,
out.new_line = nl;
out.ctx = &os;
- if (!csv_output)
- perf_stat__print_shadow_stats(counter, uval,
+ perf_stat__print_shadow_stats(counter, uval,
stat_config.aggr_mode == AGGR_GLOBAL ? 0 :
cpu_map__id_to_cpu(id),
&out);
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/9] perf, tools, stat: Move non counting counter printing to printout
From: Andi Kleen
Move the special case printing for non-running counters to
printout, so it can be shared by all the output options.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 73 ---
1 file changed, 24 insertions(+), 49 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 73b5cea..97ffe7e 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -662,6 +662,30 @@ static void printout(int id, int nr, struct perf_evsel
*counter, double uval,
os.ena = ena;
}
+ if (run == 0 || ena == 0) {
+ aggr_printout(counter, id, nr);
+
+ fprintf(stat_config.output, "%*s%s",
+ csv_output ? 0 : 18,
+ counter->supported ? CNTR_NOT_COUNTED :
CNTR_NOT_SUPPORTED,
+ csv_sep);
+
+ fprintf(stat_config.output, "%-*s%s",
+ csv_output ? 0 : unit_width,
+ counter->unit, csv_sep);
+
+ fprintf(stat_config.output, "%*s",
+ csv_output ? 0 : -25,
+ perf_evsel__name(counter));
+
+ if (counter->cgrp)
+ fprintf(stat_config.output, "%s%s",
+ csv_sep, counter->cgrp->name);
+
+ print_running(run, ena);
+ return;
+ }
+
if (nsec_counter(counter))
nsec_printout(id, nr, counter, uval);
else
@@ -711,30 +735,6 @@ static void print_aggr(char *prefix)
if (prefix)
fprintf(output, "%s", prefix);
- if (run == 0 || ena == 0) {
- aggr_printout(counter, id, nr);
-
- fprintf(output, "%*s%s",
- csv_output ? 0 : 18,
- counter->supported ? CNTR_NOT_COUNTED :
CNTR_NOT_SUPPORTED,
- csv_sep);
-
- fprintf(output, "%-*s%s",
- csv_output ? 0 : unit_width,
- counter->unit, csv_sep);
-
- fprintf(output, "%*s",
- csv_output ? 0 : -25,
- perf_evsel__name(counter));
-
- if (counter->cgrp)
- fprintf(output, "%s%s",
- csv_sep, counter->cgrp->name);
-
- print_running(run, ena);
- fputc('\n', output);
- continue;
- }
uval = val * counter->scale;
printout(id, nr, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
@@ -810,31 +810,6 @@ static void print_counter(struct perf_evsel *counter, char
*prefix)
if (prefix)
fprintf(output, "%s", prefix);
- if (run == 0 || ena == 0) {
- fprintf(output, "CPU%*d%s%*s%s",
- csv_output ? 0 : -4,
- perf_evsel__cpus(counter)->map[cpu], csv_sep,
- csv_output ? 0 : 18,
- counter->supported ? CNTR_NOT_COUNTED :
CNTR_NOT_SUPPORTED,
- csv_sep);
-
- fprintf(output, "%-*s%s",
- csv_output ? 0 : unit_width,
- counter->unit, csv_sep);
-
- fprintf(output, "%*s",
- csv_output ? 0 : -25,
- perf_evsel__name(counter));
-
- if (counter->cgrp)
- fprintf(output, "%s%s",
- csv_sep, counter->cgrp->name);
-
- print_running(run, ena);
- fputc('\n', output);
- continue;
- }
-
uval = val * counter->scale;
printout(cpu, 0, counter, uval, prefix, run, ena, 1.0);
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/9] perf, tools, stat: Move noise/running printing into printout
From: Andi Kleen
Move the running/noise printing into printout to avoid
duplicated code in the callers.
v2: Merged with other patches. Remove unnecessary hunk.
Readd hunk that ended in earlier patch.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 53 ++-
1 file changed, 11 insertions(+), 42 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index f78af2a..1d77520 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -586,7 +586,7 @@ static void abs_printout(int id, int nr, struct perf_evsel
*evsel, double avg)
}
static void printout(int id, int nr, struct perf_evsel *counter, double uval,
-char *prefix)
+char *prefix, u64 run, u64 ena, double noise)
{
struct perf_stat_output_ctx out;
struct outstate os = {
@@ -612,6 +612,12 @@ static void printout(int id, int nr, struct perf_evsel
*counter, double uval,
stat_config.aggr_mode == AGGR_GLOBAL ? 0 :
cpu_map__id_to_cpu(id),
&out);
+
+ if (!csv_output) {
+ print_noise(counter, noise);
+ if (run != ena)
+ fprintf(stat_config.output, " (%.2f%%)", 100.0 * run /
ena);
+ }
}
static void print_aggr(char *prefix)
@@ -667,11 +673,7 @@ static void print_aggr(char *prefix)
continue;
}
uval = val * counter->scale;
- printout(id, nr, counter, uval, prefix);
- if (!csv_output)
- print_noise(counter, 1.0);
-
- print_running(run, ena);
+ printout(id, nr, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
}
}
@@ -698,12 +700,7 @@ static void print_aggr_thread(struct perf_evsel *counter,
char *prefix)
fprintf(output, "%s", prefix);
uval = val * counter->scale;
- printout(thread, 0, counter, uval, prefix);
-
- if (!csv_output)
- print_noise(counter, 1.0);
-
- print_running(run, ena);
+ printout(thread, 0, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
}
}
@@ -717,7 +714,6 @@ static void print_counter_aggr(struct perf_evsel *counter,
char *prefix)
FILE *output = stat_config.output;
struct perf_stat_evsel *ps = counter->priv;
double avg = avg_stats(&ps->res_stats[0]);
- int scaled = counter->counts->scaled;
double uval;
double avg_enabled, avg_running;
@@ -727,32 +723,8 @@ static void print_counter_aggr(struct perf_evsel *counter,
char *prefix)
if (prefix)
fprintf(output, "%s", prefix);
- if (scaled == -1 || !counter->supported) {
- fprintf(output, "%*s%s",
- csv_output ? 0 : 18,
- counter->supported ? CNTR_NOT_COUNTED :
CNTR_NOT_SUPPORTED,
- csv_sep);
- fprintf(output, "%-*s%s",
- csv_output ? 0 : unit_width,
- counter->unit, csv_sep);
- fprintf(output, "%*s",
- csv_output ? 0 : -25,
- perf_evsel__name(counter));
-
- if (counter->cgrp)
- fprintf(output, "%s%s", csv_sep, counter->cgrp->name);
-
- print_running(avg_running, avg_enabled);
- fputc('\n', output);
- return;
- }
-
uval = avg * counter->scale;
- printout(-1, 0, counter, uval, prefix);
-
- print_noise(counter, avg);
-
- print_running(avg_running, avg_enabled);
+ printout(-1, 0, counter, uval, prefix, avg_running, avg_enabled, avg);
fprintf(output, "\n");
}
@@ -801,10 +773,7 @@ static void print_counter(struct perf_evsel *counter, char
*prefix)
}
uval = val * counter->scale;
- printout(cpu, 0, counter, uval, prefix);
- if (!csv_output)
- print_noise(counter, 1.0);
- print_running(run, ena);
+ printout(cpu, 0, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
}
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] tools, perf, stat: Use common printout faction to avoid duplicated code
From: Andi Kleen
Instead of every caller deciding whether to call abs or nsec printout
do it all in a single central function. No functional changes.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 57 +--
1 file changed, 20 insertions(+), 37 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 65cd26c..14b6a8a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -491,7 +491,6 @@ static void nsec_printout(int id, int nr, struct perf_evsel
*evsel, double avg)
double msecs = avg / 1e6;
const char *fmt_v, *fmt_n;
char name[25];
- int cpu = cpu_map__id_to_cpu(id);
fmt_v = csv_output ? "%.6f%s" : "%18.6f%s";
fmt_n = csv_output ? "%s" : "%-25s";
@@ -512,12 +511,6 @@ static void nsec_printout(int id, int nr, struct
perf_evsel *evsel, double avg)
if (evsel->cgrp)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
-
- if (csv_output || stat_config.interval)
- return;
-
- perf_stat__print_shadow_stats(output, evsel, avg, cpu,
- stat_config.aggr_mode);
}
static void abs_printout(int id, int nr, struct perf_evsel *evsel, double avg)
@@ -525,7 +518,6 @@ static void abs_printout(int id, int nr, struct perf_evsel
*evsel, double avg)
FILE *output = stat_config.output;
double sc = evsel->scale;
const char *fmt;
- int cpu = cpu_map__id_to_cpu(id);
if (csv_output) {
fmt = sc != 1.0 ? "%.2f%s" : "%.0f%s";
@@ -538,9 +530,6 @@ static void abs_printout(int id, int nr, struct perf_evsel
*evsel, double avg)
aggr_printout(evsel, id, nr);
- if (stat_config.aggr_mode == AGGR_GLOBAL)
- cpu = 0;
-
fprintf(output, fmt, avg, csv_sep);
if (evsel->unit)
@@ -552,12 +541,24 @@ static void abs_printout(int id, int nr, struct
perf_evsel *evsel, double avg)
if (evsel->cgrp)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
+}
- if (csv_output || stat_config.interval)
- return;
+static void printout(int id, int nr, struct perf_evsel *counter, double uval)
+{
+ int cpu = cpu_map__id_to_cpu(id);
+
+ if (stat_config.aggr_mode == AGGR_GLOBAL)
+ cpu = 0;
+
+ if (nsec_counter(counter))
+ nsec_printout(id, nr, counter, uval);
+ else
+ abs_printout(id, nr, counter, uval);
- perf_stat__print_shadow_stats(output, evsel, avg, cpu,
- stat_config.aggr_mode);
+ if (!csv_output && !stat_config.interval)
+ perf_stat__print_shadow_stats(stat_config.output, counter,
+ uval, cpu,
+ stat_config.aggr_mode);
}
static void print_aggr(char *prefix)
@@ -613,12 +614,7 @@ static void print_aggr(char *prefix)
continue;
}
uval = val * counter->scale;
-
- if (nsec_counter(counter))
- nsec_printout(id, nr, counter, uval);
- else
- abs_printout(id, nr, counter, uval);
-
+ printout(id, nr, counter, uval);
if (!csv_output)
print_noise(counter, 1.0);
@@ -649,11 +645,7 @@ static void print_aggr_thread(struct perf_evsel *counter,
char *prefix)
fprintf(output, "%s", prefix);
uval = val * counter->scale;
-
- if (nsec_counter(counter))
- nsec_printout(thread, 0, counter, uval);
- else
- abs_printout(thread, 0, counter, uval);
+ printout(thread, 0, counter, uval);
if (!csv_output)
print_noise(counter, 1.0);
@@ -703,11 +695,7 @@ static void print_counter_aggr(struct perf_evsel *counter,
char *prefix)
}
uval = avg * counter->scale;
-
- if (nsec_counter(counter))
- nsec_printout(-1, 0, counter, uval);
- else
- abs_printout(-1, 0, counter, uval);
+ printout(-1, 0, counter, uval);
print_noise(counter, avg);
@@ -760,12 +748,7 @@ static void print_counter(struct perf_evsel *counter, char
*prefix)
}
uval = val * counter->scale;
-
- if (nsec_counter(counter))
- nsec_printout(cpu, 0, counter, uval);
- else
- abs_printout(cpu, 0, counter, uval);
-
+ printout(cpu, 0, counter, uval);
if (!csv_output)
print_noise(counter, 1.0);
print_running(run, ena);
--
2.4.3
--
To unsubscribe from this lis
[PATCH 3/9] perf, tools, stat: Abstract stat metrics printing
From: Andi Kleen
Abstract the printing of shadow metrics. Instead of every
metric calling fprintf directly and taking care of indentation,
use two call backs: one to print metrics and another to
start a new line.
This will allow adding metrics to CSV mode and also
using them for other purposes.
The computation of padding is now done in the central
callback, instead of every metric doing it manually.
This makes it easier to add new metrics.
v2: Refactor functions, printout now does more. Move
shadow printing. Improve fallback callbacks. Don't
use void * callback data.
v3: Remove unnecessary hunk. Add typedef for new_line
v4: Remove unnecessary hunk. Don't print metrics for CSV/interval
mode yet. Move printout change to separate patch.
v5: Fix bisect bugs. Avoid bogus frontend cycles printing.
Fix indentation in different aggregation modes.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 59 ++--
tools/perf/util/stat-shadow.c | 211 +++---
tools/perf/util/stat.h| 15 ++-
3 files changed, 182 insertions(+), 103 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 14b6a8a..9fb8aed 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -485,6 +485,46 @@ static void aggr_printout(struct perf_evsel *evsel, int
id, int nr)
}
}
+struct outstate {
+ FILE *fh;
+};
+
+#define METRIC_LEN 35
+
+static void new_line_std(void *ctx)
+{
+ struct outstate *os = ctx;
+
+ fputc('\n', os->fh);
+ if (stat_config.aggr_mode == AGGR_NONE)
+ fprintf(os->fh, "");
+ if (stat_config.aggr_mode == AGGR_CORE)
+ fprintf(os->fh, " ");
+ if (stat_config.aggr_mode == AGGR_SOCKET)
+ fprintf(os->fh, "");
+ fprintf(os->fh, " ");
+}
+
+static void print_metric_std(void *ctx, const char *color, const char *fmt,
+const char *unit, double val)
+{
+ struct outstate *os = ctx;
+ FILE *out = os->fh;
+ int n;
+
+ if (unit == NULL || fmt == NULL) {
+ fprintf(out, "%-*s", METRIC_LEN, "");
+ return;
+ }
+
+ n = fprintf(out, " # ");
+ if (color)
+ n += color_fprintf(out, color, fmt, val);
+ else
+ n += fprintf(out, fmt, val);
+ fprintf(out, " %-*s", METRIC_LEN - n - 1, unit);
+}
+
static void nsec_printout(int id, int nr, struct perf_evsel *evsel, double avg)
{
FILE *output = stat_config.output;
@@ -545,20 +585,27 @@ static void abs_printout(int id, int nr, struct
perf_evsel *evsel, double avg)
static void printout(int id, int nr, struct perf_evsel *counter, double uval)
{
- int cpu = cpu_map__id_to_cpu(id);
+ struct outstate os = { .fh = stat_config.output };
+ struct perf_stat_output_ctx out;
+ print_metric_t pm = print_metric_std;
+ void (*nl)(void *);
- if (stat_config.aggr_mode == AGGR_GLOBAL)
- cpu = 0;
+ nl = new_line_std;
if (nsec_counter(counter))
nsec_printout(id, nr, counter, uval);
else
abs_printout(id, nr, counter, uval);
+ out.print_metric = pm;
+ out.new_line = nl;
+ out.ctx = &os;
+
if (!csv_output && !stat_config.interval)
- perf_stat__print_shadow_stats(stat_config.output, counter,
- uval, cpu,
- stat_config.aggr_mode);
+ perf_stat__print_shadow_stats(counter, uval,
+ stat_config.aggr_mode == AGGR_GLOBAL ? 0 :
+ cpu_map__id_to_cpu(id),
+ &out);
}
static void print_aggr(char *prefix)
diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 6ac0314..4d8f185 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -137,9 +137,10 @@ static const char *get_ratio_color(enum grc_type type,
double ratio)
return color;
}
-static void print_stalled_cycles_frontend(FILE *out, int cpu,
+static void print_stalled_cycles_frontend(int cpu,
struct perf_evsel *evsel
- __maybe_unused, double avg)
+ __maybe_unused, double avg,
+ struct perf_stat_output_ctx *out)
{
double total, ratio = 0.0;
const char *color;
@@ -152,14 +153,17 @@ static void print_stalled_cycles_frontend(FILE *out, int
cpu,
color = get_ratio_color(GRC_STALLED_CYCLES_FE, ratio);
- fprintf(out, " # ");
- color_fprintf(out, color, "%6.2f%%", ratio);
- fprintf(out, " frontend cycles idle ");
+ if (ratio)
+ out->
[PATCH 1/9] perf, tools, stat: Move sw clock metrics printout to stat-shadow
From: Andi Kleen
The sw clock metrics printing was missed in the earlier move to
stat-shadow of all the other metric printouts. Move it too.
Acked-by: Jiri Olsa
v2: Fix metrics printing in this version to make bisect safe.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 8 +++-
tools/perf/util/stat-shadow.c | 5 +
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 91e793a..65cd26c 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -491,6 +491,7 @@ static void nsec_printout(int id, int nr, struct perf_evsel
*evsel, double avg)
double msecs = avg / 1e6;
const char *fmt_v, *fmt_n;
char name[25];
+ int cpu = cpu_map__id_to_cpu(id);
fmt_v = csv_output ? "%.6f%s" : "%18.6f%s";
fmt_n = csv_output ? "%s" : "%-25s";
@@ -515,11 +516,8 @@ static void nsec_printout(int id, int nr, struct
perf_evsel *evsel, double avg)
if (csv_output || stat_config.interval)
return;
- if (perf_evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK))
- fprintf(output, " # %8.3f CPUs utilized ",
- avg / avg_stats(&walltime_nsecs_stats));
- else
- fprintf(output, " ");
+ perf_stat__print_shadow_stats(output, evsel, avg, cpu,
+ stat_config.aggr_mode);
}
static void abs_printout(int id, int nr, struct perf_evsel *evsel, double avg)
diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 2a5d8d7..6ac0314 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -413,6 +413,11 @@ void perf_stat__print_shadow_stats(FILE *out, struct
perf_evsel *evsel,
ratio = total / avg;
fprintf(out, " # %8.0f cycles / elision ", ratio);
+ } else if (perf_evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK)) {
+ if ((ratio = avg_stats(&walltime_nsecs_stats)) != 0)
+ fprintf(out, " # %8.3f CPUs utilized ", avg /
ratio);
+ else
+ fprintf(out, " ");
} else if (runtime_nsecs_stats[cpu].n != 0) {
char unit = 'M';
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] perf, tools, stat: Add support for metrics in interval mode
From: Andi Kleen
Now that we can modify the metrics printout functions easily,
it's straight forward to support metric printing for interval mode.
All that is needed is to print the time stamp on every new line.
Pass the prefix into the context and print it out.
v2: Move wrong hunk to here.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 9fb8aed..f78af2a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -487,6 +487,7 @@ static void aggr_printout(struct perf_evsel *evsel, int id,
int nr)
struct outstate {
FILE *fh;
+ const char *prefix;
};
#define METRIC_LEN 35
@@ -496,6 +497,7 @@ static void new_line_std(void *ctx)
struct outstate *os = ctx;
fputc('\n', os->fh);
+ fputs(os->prefix, os->fh);
if (stat_config.aggr_mode == AGGR_NONE)
fprintf(os->fh, "");
if (stat_config.aggr_mode == AGGR_CORE)
@@ -583,10 +585,14 @@ static void abs_printout(int id, int nr, struct
perf_evsel *evsel, double avg)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
}
-static void printout(int id, int nr, struct perf_evsel *counter, double uval)
+static void printout(int id, int nr, struct perf_evsel *counter, double uval,
+char *prefix)
{
- struct outstate os = { .fh = stat_config.output };
struct perf_stat_output_ctx out;
+ struct outstate os = {
+ .fh = stat_config.output,
+ .prefix = prefix ? prefix : ""
+ };
print_metric_t pm = print_metric_std;
void (*nl)(void *);
@@ -601,7 +607,7 @@ static void printout(int id, int nr, struct perf_evsel
*counter, double uval)
out.new_line = nl;
out.ctx = &os;
- if (!csv_output && !stat_config.interval)
+ if (!csv_output)
perf_stat__print_shadow_stats(counter, uval,
stat_config.aggr_mode == AGGR_GLOBAL ? 0 :
cpu_map__id_to_cpu(id),
@@ -661,7 +667,7 @@ static void print_aggr(char *prefix)
continue;
}
uval = val * counter->scale;
- printout(id, nr, counter, uval);
+ printout(id, nr, counter, uval, prefix);
if (!csv_output)
print_noise(counter, 1.0);
@@ -692,7 +698,7 @@ static void print_aggr_thread(struct perf_evsel *counter,
char *prefix)
fprintf(output, "%s", prefix);
uval = val * counter->scale;
- printout(thread, 0, counter, uval);
+ printout(thread, 0, counter, uval, prefix);
if (!csv_output)
print_noise(counter, 1.0);
@@ -742,7 +748,7 @@ static void print_counter_aggr(struct perf_evsel *counter,
char *prefix)
}
uval = avg * counter->scale;
- printout(-1, 0, counter, uval);
+ printout(-1, 0, counter, uval, prefix);
print_noise(counter, avg);
@@ -795,7 +801,7 @@ static void print_counter(struct perf_evsel *counter, char
*prefix)
}
uval = val * counter->scale;
- printout(cpu, 0, counter, uval);
+ printout(cpu, 0, counter, uval, prefix);
if (!csv_output)
print_noise(counter, 1.0);
print_running(run, ena);
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] backlight: gpio-backlight: use default-on on GPIO request
There are situations where the backlight should be on at boot time
(e.g. if the boot loader already turned the display on). The DT
bindings specify the "default-on" property for that purpose.
Currently, the initial state of the GPIO at request time is always
set to logical off (high or low depending on whether it is an
active high or low GPIO). Since the GPIO is requested as an output,
the GPIO will be driven low for a short period of time, which leads
to a flickering display in the above use-case.
Initialize the GPIO depending on the default-on property to be
logical on or off.
Signed-off-by: Stefan Agner
---
drivers/video/backlight/gpio_backlight.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index 5fbbc2e..1813441 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -89,6 +89,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
struct backlight_device *bl;
struct gpio_backlight *gbl;
struct device_node *np = pdev->dev.of_node;
+ unsigned long flags = GPIOF_DIR_OUT;
int ret;
if (!pdata && !np) {
@@ -114,9 +115,12 @@ static int gpio_backlight_probe(struct platform_device
*pdev)
gbl->def_value = pdata->def_value;
}
- ret = devm_gpio_request_one(gbl->dev, gbl->gpio, GPIOF_DIR_OUT |
- (gbl->active ? GPIOF_INIT_LOW
-: GPIOF_INIT_HIGH),
+ if (gbl->active)
+ flags |= gbl->def_value ? GPIOF_INIT_HIGH : GPIOF_INIT_LOW;
+ else
+ flags |= gbl->def_value ? GPIOF_INIT_LOW : GPIOF_INIT_HIGH;
+
+ ret = devm_gpio_request_one(gbl->dev, gbl->gpio, flags,
pdata ? pdata->name : "backlight");
if (ret < 0) {
dev_err(&pdev->dev, "unable to request GPIO\n");
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] block: enable dax for raw block devices
On Thu, Oct 22, 2015 at 2:08 PM, Jan Kara wrote: > On Thu 22-10-15 16:05:46, Williams, Dan J wrote: [..] >> This text was aimed at the request from Ross to document the differences >> vs the generic_file_mmap() path. Is the following incremental change >> more clear? > > Well, not really. I thought you'd just delete that paragraph :) The thing > is: When doing IO directly to the block device, it makes no sense to look > at a filesystem on top of it - hopefully there is none since you'd be > corrupting it. So the paragraph that would make sense to me would be: > > * Finally, in contrast to filemap_page_mkwrite(), we don't bother calling > * sb_start_pagefault(). There is no filesystem which could be frozen here > * and when bdev gets frozen, IO gets blocked in the request queue. I'm not following this assertion that "IO gets blocked in the request queue" when the device is frozen in the code. As far as I can see outside of tracking the freeze depth count the request_queue does not check if the device is frozen. freeze_bdev() is moot when no filesystem is a present. > But when spelled out like this, I've realized that with DAX, this blocking > of requests in the request queue doesn't really block the IO to the device. > So block device freezing (aka blk_queue_stop()) doesn't work reliably with > DAX. That should be fixed but it's not easy as the only way to do that > would be to hook into blk_stop_queue() and unmap (or at least > write-protect) all the mappings of the device. Ugh... Again I'm missing how this is guaranteed in the non-DAX case. freeze_bdev() will sync_blockdev(), but it does nothing to prevent re-dirtying through raw device mmaps while the fs in frozen. Should it? That's at least a separate patch. > Ugh2: Now I realized that DAX mmap isn't safe wrt fs freezing even for > filesystems since there's nothing which writeprotects pages that are > writeably mapped. In normal path, page writeback does this but that doesn't > happen for DAX. I remember we once talked about this but it got lost. > We need something like walk all filesystem inodes during fs freeze and > writeprotect all pages that are mapped. But that's going to be slow... This is what I'm attempting to tackle with the next revision of this series... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] scsi: remove useless casting value returned by kmalloc to structure
Reviewed-by: Matthew R. Ochs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tty: synclinkmp: do not ignore errors in probe()
synclinkmp_init_one() ignores all errors and does not release
all resources if something fails.
The patch adds returned code to device_init() and add_device()
and proper error handling.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/tty/synclinkmp.c | 44
1 file changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/tty/synclinkmp.c b/drivers/tty/synclinkmp.c
index 08633a8139ff..5b622788d4bf 100644
--- a/drivers/tty/synclinkmp.c
+++ b/drivers/tty/synclinkmp.c
@@ -549,8 +549,8 @@ static int tiocmset(struct tty_struct *tty,
unsigned int set, unsigned int clear);
static int set_break(struct tty_struct *tty, int break_state);
-static void add_device(SLMP_INFO *info);
-static void device_init(int adapter_num, struct pci_dev *pdev);
+static int add_device(SLMP_INFO *info);
+static int device_init(int adapter_num, struct pci_dev *pdev);
static int claim_resources(SLMP_INFO *info);
static void release_resources(SLMP_INFO *info);
@@ -3703,7 +3703,7 @@ static void release_resources(SLMP_INFO *info)
/* Add the specified device instance data structure to the
* global linked list of devices and increment the device count.
*/
-static void add_device(SLMP_INFO *info)
+static int add_device(SLMP_INFO *info)
{
info->next_device = NULL;
info->line = synclinkmp_device_count;
@@ -3741,7 +3741,9 @@ static void add_device(SLMP_INFO *info)
info->max_frame_size );
#if SYNCLINK_GENERIC_HDLC
- hdlcdev_init(info);
+ return hdlcdev_init(info);
+#else
+ return 0;
#endif
}
@@ -3830,10 +3832,10 @@ static SLMP_INFO *alloc_dev(int adapter_num, int
port_num, struct pci_dev *pdev)
return info;
}
-static void device_init(int adapter_num, struct pci_dev *pdev)
+static int device_init(int adapter_num, struct pci_dev *pdev)
{
SLMP_INFO *port_array[SCA_MAX_PORTS];
- int port;
+ int port, rc;
/* allocate device instances for up to SCA_MAX_PORTS devices */
for ( port = 0; port < SCA_MAX_PORTS; ++port ) {
@@ -3843,14 +3845,16 @@ static void device_init(int adapter_num, struct pci_dev
*pdev)
tty_port_destroy(&port_array[port]->port);
kfree(port_array[port]);
}
- return;
+ return -ENOMEM;
}
}
/* give copy of port_array to all ports and add to device list */
for ( port = 0; port < SCA_MAX_PORTS; ++port ) {
memcpy(port_array[port]->port_array,port_array,sizeof(port_array));
- add_device( port_array[port] );
+ rc = add_device( port_array[port] );
+ if (rc)
+ goto err_add;
spin_lock_init(&port_array[port]->lock);
}
@@ -3870,21 +3874,30 @@ static void device_init(int adapter_num, struct pci_dev
*pdev)
alloc_dma_bufs(port_array[port]);
}
- if ( request_irq(port_array[0]->irq_level,
+ rc = request_irq(port_array[0]->irq_level,
synclinkmp_interrupt,
port_array[0]->irq_flags,
port_array[0]->device_name,
- port_array[0]) < 0 ) {
+ port_array[0]);
+ if ( rc ) {
printk( "%s(%d):%s Can't request interrupt, IRQ=%d\n",
__FILE__,__LINE__,
port_array[0]->device_name,
port_array[0]->irq_level );
+ goto err_irq;
}
- else {
- port_array[0]->irq_requested = true;
- adapter_test(port_array[0]);
- }
+ port_array[0]->irq_requested = true;
+ adapter_test(port_array[0]);
}
+ return 0;
+err_irq:
+ release_resources( port_array[0] );
+err_add:
+ for ( port = 0; port < SCA_MAX_PORTS; ++port ) {
+ tty_port_destroy(&port_array[port]->port);
+ kfree(port_array[port]);
+ }
+ return rc;
}
static const struct tty_operations ops = {
@@ -5599,8 +5612,7 @@ static int synclinkmp_init_one (struct pci_dev *dev,
printk("error enabling pci device %p\n", dev);
return -EIO;
}
- device_init( ++synclinkmp_adapter_count, dev );
- return 0;
+ return device_init( ++synclinkmp_adapter_count, dev );
}
static void synclinkmp_remove_one (struct pci_dev *dev)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH 4/9] dma: fix a trivial typo
On Sun, Oct 18, 2015 at 5:31 PM, Geliang Tang wrote: > s/regsiter/register/ > > Signed-off-by: Geliang Tang Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] scsi: lpfc: Use kzalloc instead of kmalloc
Hi Punit,
Aren't you missing the removal of the memset() as part of this conversion?
-matt
> On Oct 23, 2015, at 3:03 PM, Punit Vara wrote:
>
> This patch is to the lpfc_els.c which resolves following warning
> reported by coccicheck:
>
> WARNING: kzalloc should be used for rdp_context, instead of
> kmalloc/memset
>
> Signed-off-by: Punit Vara
> ---
> drivers/scsi/lpfc/lpfc_els.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
> index 36bf58b..422c800 100644
> --- a/drivers/scsi/lpfc/lpfc_els.c
> +++ b/drivers/scsi/lpfc/lpfc_els.c
> @@ -4990,7 +4990,7 @@ lpfc_els_rcv_rdp(struct lpfc_vport *vport, struct
> lpfc_iocbq *cmdiocb,
> if (RDP_NPORT_ID_SIZE !=
> be32_to_cpu(rdp_req->nport_id_desc.length))
> goto rjt_logerr;
> - rdp_context = kmalloc(sizeof(struct lpfc_rdp_context), GFP_KERNEL);
> + rdp_context = kzalloc(sizeof(struct lpfc_rdp_context), GFP_KERNEL);
> if (!rdp_context) {
> rjt_err = LSRJT_UNABLE_TPC;
> goto error;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.2 00/54] 4.2.5-stable review
On Fri, Oct 23, 2015 at 03:54:59PM -0600, Shuah Khan wrote: > On 10/23/2015 11:44 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.2.5 release. > > There are 54 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Oct 25 17:45:07 UTC 2015. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.2.5-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.1 00/46] 4.1.12-stable review
On Fri, Oct 23, 2015 at 02:34:56PM -0600, Shuah Khan wrote:
> On 10/23/2015 11:45 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.1.12 release.
> > There are 46 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Oct 25 17:46:11 UTC 2015.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.1.12-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> I am seeing the following compile error (was seen in 4.2.4-rc1)
>
> In file included from include/uapi/linux/stddef.h:1:0,
> from include/linux/stddef.h:4,
> from ./include/uapi/linux/posix_types.h:4,
> from include/uapi/linux/types.h:13,
> from include/linux/types.h:5,
> from include/uapi/linux/capability.h:16,
> from include/linux/capability.h:15,
> from include/linux/sched.h:15,
> from drivers/xen/preempt.c:12:
> drivers/xen/preempt.c: In function ‘xen_maybe_preempt_hcall’:
> drivers/xen/preempt.c:34:11: error: too few arguments to function
> ‘should_resched’
> && should_resched())) {
>^
> include/linux/compiler.h:164:42: note: in definition of macro ‘unlikely’
> # define unlikely(x) __builtin_expect(!!(x), 0)
> ^
> In file included from include/linux/preempt.h:18:0,
> from include/linux/spinlock.h:50,
> from include/linux/seqlock.h:35,
> from include/linux/time.h:5,
> from include/uapi/linux/timex.h:56,
> from include/linux/timex.h:56,
> from include/linux/sched.h:19,
> from drivers/xen/preempt.c:12:
> ./arch/x86/include/asm/preempt.h:93:29: note: declared here
> static __always_inline bool should_resched(int preempt_offset)
> ^
> scripts/Makefile.build:258: recipe for target 'drivers/xen/preempt.o' failed
> make[2]: *** [drivers/xen/preempt.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> scripts/Makefile.build:403: recipe for target 'drivers/xen' failed
> make[1]: *** [drivers/xen] Error 2
> Makefile:947: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
Thanks for reporting this, there's a -rc2 tarball:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.1.12-rc2.gz
that should fix it, can you test that?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.1 39/46] sched/preempt: Fix cond_resched_lock() and cond_resched_softirq()
On Fri, Oct 23, 2015 at 11:14:30PM +0300, Thomas Backlund wrote:
> Den 23.10.2015 kl. 20:46, skrev Greg Kroah-Hartman:
> >4.1-stable review patch. If anyone has any objections, please let me know.
> >
> >--
> >
> >From: Konstantin Khlebnikov
> >
> >commit fe32d3cd5e8eb0f82e459763374aa80797023403 upstream.
>
> This one broke drivers/xen/ build
>
>
> drivers/xen/preempt.c: In function ”xen_maybe_preempt_hcall”:
> drivers/xen/preempt.c:34:11: error: too few arguments to function
> ”should_resched”
> && should_resched())) {
>^
>
>
> Needed fix is:
>
> From 0fa2f5cb2b0ecd8d56baa51f35f09aab234eb0bf Mon Sep 17 00:00:00 2001
> From: Konstantin Khlebnikov
> Date: Wed, 15 Jul 2015 12:52:01 +0300
> Subject: [PATCH] sched/preempt, xen: Use need_resched() instead of
> should_resched()
Thanks, now queued up.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
On Fri, Oct 23, 2015 at 07:46:39AM -0500, Andrew F. Davis wrote: > I know just because other drivers do it doesn't mean it's a good idea, > but this is not new for MFDs and it is done in other regulators as well > (mt6397, tps659038, qcom,spmi, etc..). mt6397 doesn't do this, it doesn't have a compatible string at all (it's doing what I'm recommending that you do). The SPMI devices are standalone devices, their parent device is actually functioning as a bus controller here (it's really a microcontroller inside the SoC). The Palmas is part of how we realised this was a problem. > >It seems like this is describing how Linux > >loads drivers not how the hardware is constructed but DT should describe > >the hardware. > While I agree to a point, if we follow this to its logical conclusion we > would end up with one compatible binding per SoC and be basically back to > board files. We need some granularity, just finding out where is the issue, The fact that the SoC DT is not distinct from the board DT is actually one of the problems with the way we're using DT at the minute, it means that DTBs are much less stable than they should be since we can enhance support for SoCs but DTBs need regenerating to take advantage of it. It would be much better if the boards just referenced the SoC they use and pulled in a separate definition of the SoC (DT overlays will make it much more tractable to implement that if someone has time...). > I would say that as these devices belong to different subsystems and are > almost completely independent there should be no problem with having their > own compatible matched hardware sub-node. All it's adding is more typing for users. signature.asc Description: PGP signature
[PATCH v7] Documentation: add Device tree bindings for hwmon/nct7802
Introduced subnodes sensor, fan and peci with properties.
Signed-off-by: Constantine Shulyupin
---
Changed in v7:
- sensors type (thermistor, thermistor, voltage) and pwm type
selected with type property instead of compatible property.
Changed in v6:
- Removed previous definition.
- Introduced subnodes sensor, fan and peci with properties.
Changed in v5:
- Fixed typos
Changed in v4:
- Removed registers initialization by names
- Added properties nuvoton,sensor*-type
Changed in v3:
- Fixed vendor prefix
- Added short registers description,
full registers description is available at
https://www.nuvoton.com/hq/products/cloud-computing/hardware-monitors/desktop-server-series/nct7802y/
Changed in v2:
- Removed nct7802,reg-init
- Added registers initialization by names
Introduced in v1:
- nct7802,reg-init
---
.../devicetree/bindings/hwmon/nct7802.txt | 77 ++
1 file changed, 77 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/nct7802.txt
diff --git a/Documentation/devicetree/bindings/hwmon/nct7802.txt
b/Documentation/devicetree/bindings/hwmon/nct7802.txt
new file mode 100644
index 000..1619202
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/nct7802.txt
@@ -0,0 +1,77 @@
+Nuvoton NCT7802Y Hardware Monitoring IC
+
+Required node properties:
+
+ - "compatible": must be "nuvoton,nct7802"
+ - "reg": I2C bus address of the device
+ - #address-cells=<1>;
+ - #size-cells=<0>;
+
+Optional subnodes:
+
+Sensor subnodes properties:
+ - "reg": index in range 0..2
+ - "compatible", allowed values:
+- "nuvoton,nct7802"
+ - "sensor-type", allowed values:
+ "thermal-diode"
+ "thermistor"
+ "voltage"
+
+Except sensor at address 2 can't be "thermal-diode".
+
+Fan subnode:
+
+Required properties:
+ - "reg" :index of in range 0 .. 2.
+ - "compatible", should be "nuvoton,nct7802-fan"
+Optional boolean properties:
+ - "direct-current" :direct current powered fan instead default PWM
+ - "invert" :inverted polarity
+ - "open-drain" :open-drain output instead push pull
+
+Subnode "peci" properties:
+ - "reg" :index in range 0..1
+ - "compatible", should be "nuvoton,nct7802-peci"
+
+Subnode vcc properties:
+ - "compatible", should be "nuvoton,nct7802-vcc"
+
+Subnode vcore properties:
+ - "compatible", should be "nuvoton,nct7802-vcore"
+
+Not defined sensors, fans and PECI modules will be disabled.
+
+Example nct7802 node:
+
+nct7802 {
+ compatible = "nuvoton,nct7802";
+ reg = <0x2a>;
+ #address-cells=<1>;
+ #size-cells=<0>;
+ sensor@0 {
+ reg = <0>;
+ compatible = "nuvoton,nct7802";
+ sensor-type = "thermistor"
+ };
+ sensor@1 {
+ reg = <1>;
+ compatible = "nuvoton,nct7802";
+ sensor-type = "thermal-diode";
+ };
+ pwm-fan@0 {
+ reg = <0>;
+ compatible = "nuvoton,nct7802-fan";
+ };
+ dc-fan@1 {
+ reg = <1>;
+ compatible = "nuvoton,nct7802-fan";
+ dc;
+ invert;
+ open-drain;
+ };
+ peci@0 {
+ reg = <0>;
+ compatible = "nuvoton,nct7802-peci";
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] GHES: Fix cached error-status
> ping? I'm not actually sure that the code is wrong. As you say it is a pretty strange loop. We seem to want to look at a bunch of conditions, and use "continue" to ignore bits until we find one that we like the look of. Perhaps as soon as we do, we want to believe it to get our return value? Perhaps the code knows that we won't find another section that matches all the tests, so it isn't worth going around the loop again. Ying: You wrote this code 4 years ago. Any recollections of why it looks like it does? -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH V2 06/10] ASoC: img: Add driver for parallel output controller
On Thu, Oct 22, 2015 at 08:21:03PM +0100, Damien Horsley wrote:
> On 19/10/15 19:07, Mark Brown wrote:
> > On Mon, Oct 12, 2015 at 01:40:33PM +0100, Damien Horsley wrote:
> >> + spin_lock_irqsave(&prl->lock, flags);
> >> + reg = img_prl_out_readl(prl, IMG_PRL_OUT_CTL);
> >> + ucontrol->value.integer.value[0] = !!(reg & IMG_PRL_OUT_CTL_EDGE_MASK);
> >> + spin_unlock_irqrestore(&prl->lock, flags);
> > Do you need to lock a single register read?
> Between the calls to reset_control_assert and reset_control_deassert,
> the block is held in reset. During this time, no register access will
> succeed. All register access that may occur concurrently with the reset
> needs to be locked
Add a comment so readers know this.
> >> +static struct snd_kcontrol_new img_prl_out_controls[] = {
> >> + {
> >> + .iface = SNDRV_CTL_ELEM_IFACE_PCM,
> >> + .name = "Parallel Out Edge Falling",
> >> + .info = img_prl_out_edge_info,
> >> + .get = img_prl_out_get_edge,
> >> + .put = img_prl_out_set_edge
> >> + }
> >> +};
> > If this is a boolean control (it looked like one) it should be called
> > Switch but it's not clear to me what exactly is being controlled here or
> > why it's something that should be exposed to userspace.
> This controls the edge (rising/falling) of the frame clock that the
> samples are generated on. Should I create a set_fmt function and use
> SND_SOC_DAIFMT_NB_NF / SND_SOC_DAIFMT_NB_IF to set this instead? I
> wasn't sure if those formats were just for I2S or not
Yes, that's part of the DAI format - and we definitely don't want users
randomly changing this at runtime, the CODEC and CPU need to be
configured together.
signature.asc
Description: PGP signature
Re: [alsa-devel] [PATCH V2 02/10] ASoC: img: Add driver for I2S input controller
On Thu, Oct 22, 2015 at 08:09:38PM +0100, Damien Horsley wrote:
> On 19/10/15 18:47, Mark Brown wrote:
> > On Mon, Oct 12, 2015 at 01:40:29PM +0100, Damien Horsley wrote:
> > The APIs here all seem a bit odd - for example the enable API taking a
> > register value as an argument (normally reg is a register address BTW)
> > and returning a value but the disable API doing a read/modify/write
> > cycle.
> Sure. It reduces the number of register accesses this way, but the
> difference in execution time is not significant. Would you prefer these
> to both do read-modify-writes?
I would prefer that the functions look consistent with each other and
ideally resemble common register acceess idioms in the kernel.
> >> +static inline void img_i2s_in_flush(struct img_i2s_in *i2s)
> >> +{
> >> + int i;
> >> + u32 reg;
> >> +
> >> + for (i = 0; i < i2s->active_channels; i++) {
> >> + reg = img_i2s_in_ch_disable(i2s, i);
> >> + reg |= IMG_I2S_IN_CH_CTL_FIFO_FLUSH_MASK;
> >> + img_i2s_in_ch_writel(i2s, i, reg, IMG_I2S_IN_CH_CTL);
> >> + reg &= ~IMG_I2S_IN_CH_CTL_FIFO_FLUSH_MASK;
> >> + img_i2s_in_ch_writel(i2s, i, reg, IMG_I2S_IN_CH_CTL);
> >> + img_i2s_in_ch_enable(i2s, i, reg);
> >> + }
> >> +}
> > This all seems to be connected to this, which is itself slightly funky
> > especially in the context of the only user...
> They are also used during hw_params and set_format.
My point is that the flush function has only one user.
> >> + case SNDRV_PCM_TRIGGER_STOP:
> >> + case SNDRV_PCM_TRIGGER_SUSPEND:
> >> + case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> >> + reg = img_i2s_in_readl(i2s, IMG_I2S_IN_CTL);
> >> + reg &= ~IMG_I2S_IN_CTL_ME_MASK;
> >> + img_i2s_in_writel(i2s, reg, IMG_I2S_IN_CTL);
> >> + img_i2s_in_flush(i2s);
> >> + break;
> > ...which looks like it'll enable everything, then disable and reenable.
> > Plus needing to do a flush on trigger seems weird.
> If the FIFOs are not flushed, some samples from the previous stream will
> be transferred to the user application when the block is started again
Shouldn't we be doing that flush on stream close instead? If nothing
else the flush is going to discard a bit of data if the stream is just
paused.
> >> + if ((channels < 2) ||
> >> + (channels > (i2s->max_i2s_chan * 2)) ||
> >> + (channels % 2))
> >> + return -EINVAL;
> > This indentation is very weird.
> Ok. What is the correct indentation for this?
Align the continuation lines of the if condition with the first line.
signature.asc
Description: PGP signature
Re: [PATCH] GHES: Fix cached error-status
ping? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ARM: BCM: Add SMP support for Broadcom 4708
On 10/15/2015 08:14 PM, Jon Mason wrote:
> ARM: BCM: Add SMP support for Broadcom 4708
>
> Add SMP support for Broadcom's 4708 SoCs.
I tested this and it works on my device, it is also in OpenWrt now:
https://dev.openwrt.org/browser/trunk/target/linux/bcm53xx/patches-4.1/131-ARM-BCM-Add-SMP-support-for-Broadcom-4708.patch?rev=47247
>
> Signed-off-by: Jon Mason
> ---
> arch/arm/boot/dts/bcm4708.dtsi | 2 ++
> arch/arm/boot/dts/bcm94708.dts | 2 +-
> arch/arm/mach-bcm/Kconfig | 1 +
> arch/arm/mach-bcm/Makefile | 3 +++
> 4 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
> index 31141e8..22a41df 100644
> --- a/arch/arm/boot/dts/bcm4708.dtsi
> +++ b/arch/arm/boot/dts/bcm4708.dtsi
> @@ -15,6 +15,8 @@
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> + enable-method = "brcm,bcm-nsp-smp";
> + secondary-boot-reg = <0x0400>;
>
> cpu@0 {
> device_type = "cpu";
> diff --git a/arch/arm/boot/dts/bcm94708.dts b/arch/arm/boot/dts/bcm94708.dts
> index f60bb1d..49682d6 100644
> --- a/arch/arm/boot/dts/bcm94708.dts
> +++ b/arch/arm/boot/dts/bcm94708.dts
> @@ -32,7 +32,7 @@
>
> /dts-v1/;
>
> -#include "bcm5301x.dtsi"
> +#include "bcm4708.dtsi"
This is already changed in the patch adding this file.
>
> / {
> model = "NorthStar SVK (BCM94708)";
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index 2e9dbb5..4fc8fa3 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -54,6 +54,7 @@ config ARCH_BCM_NSP
> config ARCH_BCM_5301X
> bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7
> select ARCH_BCM_IPROC
> + select HAVE_SMP
probably this is also needed:
select ARM_ERRATA_764369 if SMP
The CPU should be affected by this issue.
> help
> Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores.
>
> diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> index 36a4ca30..3ca1cf1 100644
> --- a/arch/arm/mach-bcm/Makefile
> +++ b/arch/arm/mach-bcm/Makefile
> @@ -43,6 +43,9 @@ obj-$(CONFIG_ARCH_BCM2835) += board_bcm2835.o
>
> # BCM5301X
> obj-$(CONFIG_ARCH_BCM_5301X) += bcm_5301x.o
> +ifeq ($(CONFIG_ARCH_BCM_5301X),y)
> +obj-$(CONFIG_SMP)+= headsmp.o platsmp.o
> +endif
>
> # BCM63XXx
> ifeq ($(CONFIG_ARCH_BCM_63XX),y)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy
Hello, Paul. On Thu, Oct 15, 2015 at 04:42:37AM -0700, Paul Turner wrote: > > The thing which bothers me the most is that cpuset behavior is > > different from global case for no good reason. > > I've tried to explain above that I believe there are reasonable > reasons for it working the way it does from an interface perspective. > I do not think they can be so quickly discarded out of hand. However, > I think we should continue winnowing focus and first resolve the model > of interaction for sub-process hierarchies, One way or the other, I think the kernel needs to sort out how task affinity masks are handled when the available CPUs change, be that from CPU hotplug or cpuset config changes. On forcing all affinity masks to the set of available CPUs, I'm still not convinced that it's a useful extra behavior to implement for cpuset especially given that the same can be achieved from userland without too much difficulty. This goes back to the argument for implmenting the minimal set of functionality which can be used as building blocks. Updating all task affinty masks is an irreversible destructive operation. It doesn't enable anything which can't be otherwise but does end up restricting how the feature can be used. But yeah, let's shelve this subject for now. > > Now, if you make the in-process grouping dynamic and accessible to > > external entities (and if we aren't gonna do that, why even bother?), > > this breaks down and we have some of the same problems we have with > > allowing applications to directly manipulate cgroup sub-directories. > > This is a fundamental problem. Setting attributes can be shared but > > organization is an exclusive process. You can't share that without > > close coordination. > > Your concern here is centered on permissions, not the interface. > > This seems directly remedied by exactly: > Any sub-process hierarchy we exposed would be locked down in terms > of write access. These would not be generally writable. You're > absolutely correct that you can't share without close coordination, > and granting the appropriate permissions is part of that. It is not about permissions. It is about designing an interface which guarantees certain set of invariants regardless of priviledges - even root can't violate such invariants short of injecting code into and modifying the behavior of the target process. This isn't anything unusual. In fact, permission based access control is something which is added if and only if allowing and controlling accesses from multiple parties is necessary and needs to be explicitly justified. If coordination in terms of thread hierarchy organization from the target process is needed for allowing external entities to twiddle with resource distribution, no capability is lost by making the organization solely the responsibility of the target process while gaining a lot stronger set of behavioral invariants. I can't see strong enough justifications for allowing external entities to manipulate in-process thread organization. > > assigning the full responsiblity of in-process organization to the > > application itself and tying it to static parental relationship allows > > for solid common grounds where these resource operations can be > > performed by different entities without causing structural issues just > > like other similar operations. > > But cases have already been presented above where the full > responsibility cannot be delegated to the application. Because we > explicitly depend on constraints being provided by the external > environment. I don't think such cases have been presented. The only thing necessary is the target processes organizing threads in a way which allows external agents to apply external constraints. > > It's not that but more about what the file-system interface implies. > > It's not just different. It breaks a lot of expectations a lot of > > application visible kernel interface provides as explained above. > > There are reasons why we usually don't do things this way. > > The arguments you've made above are largely centered on permissions > and the right to make modifications. I don't see what other > expectations you believe are being broken here. This still feels like > an aesthetic objection. I hope my points are clear by now. > > It does require the applications to follow certain protocols to > > organize itself but this is a pretty trivial thing to do and comes > > with the benefit that we don't need to introduce a completely new > > grouping concept to applications. > > I strongly disagree here: Applications today do _not_ use sub-process > clone hierarchies today. As a result, this _is_ introducing a > completely new grouping concept because it's one applications have > never cared about outside of a shell implementation. It is a logical extension of how the kernel organizes processes in the system. It's a lot more native to how programs usually interact with the system than meddlin
Re: [PATCH] timer: Lazily wakup nohz CPU when adding new timer.
On Fri, Oct 23, 2015 at 07:49:51AM +0530, Viresh Kumar wrote: > On 22-10-15, 14:40, Yunhong Jiang wrote: > > A naive question is, why it's sure a tick will happen when the tickless > > processor is in idle? > > How do you get this impression? I don't think anyone has said that. Viresh, thanks for your reply for my question. I got this impression from Frederic's comments on http://marc.info/?l=linux-kernel&m=139048415303210&w=2, "So you simply rely on the next tick to see the new timer. This should work with CONFIG_NO_HZ_IDLE but not with CONFIG_NO_HZ_FULL since the target may be running without the tick". Per my understanding of this comment, it means we can rely on the next tick for CONFIG_NO_HZ_IDLE, which means it's sure a tick will happen for CONFIG_NO_HZ_IDLE, am I right? > > We are talking about deferrable timers, which by design are only > required if the target CPU is not-idle. If it is idle, then the timer > isn't required to be serviced until the CPU wakes up. And the CPU can > take whatever time it wants to wake up again. Hmm, per http://lxr.free-electrons.com/source/include/linux/timer.h#L51, the deferreable timer will be serviced when the CPU eventually wakes up "with a subsequent non-deferrable timer". If there is no non-deferrable timer, based on Frederic's comments, we in fact depends on next tick. My confusion is, why we are sure there is next tick on CONFIG_NO_HZ_IDLE idle processor to wake it up. If there is no tick, and no other timer, will the timer get no chance to be waken up at all? I don't think "deferred for ever" is deferreable. Thanks -jyh > > > Is it because scheduler load balance is sure to send a > > tick to the processor in future? > > No. We aren't expecting the CPU to wake up any time soon. Just ignore > the deferrable timer. > > -- > viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] irqchip/gic: assign irqchip dynamically
Instead of having the irqchip being a static struct, make it part
of the per-instance data so we can assign it a dynamic name. This
has the usable side effect of displaying the GIC with an instance
number as GIC0, GIC1 ... GICn in /proc/interrupts, which is helpful
when debugging cascaded GICs, such as on the ARM PB11MPCore.
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Keep the static structs around, just delete the .name
field assign them to the chips at registration time, updating
the name field with the instance number.
- Also enumerate the EOIMODE1 sub-chips.
- Broke out this irqchip stuff from the rest of the series so as
not to stress the irqchip maintainers. It has no dependencies
on the other patches anyways, and can be merged stand-alone.
Marc: can't test the EOIMODE1 thing, it's far above me, but it
"should work". Is it correct that there is one unique and coupled
EOIMODE1 instance per GIC instance like this?
---
drivers/irqchip/irq-gic.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 9ec8cf5137d9..fe87ac32fdbe 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -58,6 +58,8 @@ union gic_base {
};
struct gic_chip_data {
+ struct irq_chip chip;
+ struct irq_chip eoimode1_chip;
union gic_base dist_base;
union gic_base cpu_base;
#ifdef CONFIG_CPU_PM
@@ -370,7 +372,6 @@ static void gic_handle_cascade_irq(struct irq_desc *desc)
}
static struct irq_chip gic_chip = {
- .name = "GIC",
.irq_mask = gic_mask_irq,
.irq_unmask = gic_unmask_irq,
.irq_eoi= gic_eoi_irq,
@@ -386,7 +387,6 @@ static struct irq_chip gic_chip = {
};
static struct irq_chip gic_eoimode1_chip = {
- .name = "GICv2",
.irq_mask = gic_eoimode1_mask_irq,
.irq_unmask = gic_unmask_irq,
.irq_eoi= gic_eoimode1_eoi_irq,
@@ -880,11 +880,12 @@ void __init gic_init_physaddr(struct device_node *node)
static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hw)
{
- struct irq_chip *chip = &gic_chip;
+ struct gic_chip_data *gic = d->host_data;
+ struct irq_chip *chip = &gic->chip;
if (static_key_true(&supports_deactivate)) {
if (d->host_data == (void *)&gic_data[0])
- chip = &gic_eoimode1_chip;
+ chip = &gic->eoimode1_chip;
}
if (hw < 32) {
@@ -989,6 +990,13 @@ static void __init __gic_init_bases(unsigned int gic_nr,
int irq_start,
BUG_ON(gic_nr >= MAX_GIC_NR);
gic = &gic_data[gic_nr];
+
+ /* Initialize irq_chip */
+ gic->chip = gic_chip;
+ gic->eoimode1_chip = gic_eoimode1_chip;
+ gic->chip.name = kasprintf(GFP_KERNEL, "GIC%d", gic_nr);
+ gic->eoimode1_chip.name = kasprintf(GFP_KERNEL, "GICv2%d", gic_nr);
+
#ifdef CONFIG_GIC_NON_BANKED
if (percpu_offset) { /* Frankein-GIC without banked registers... */
unsigned int cpu;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
