* Re: [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
From: Pandiyan, Dhinakaran @ 2016-11-14 21:35 UTC (permalink / raw)
To: Navare, Manasi D; +Cc: Nikula, Jani, intel-gfx@lists.freedesktop.org
In-Reply-To: <20161110233256.GA4623@intel.com>
On Thu, 2016-11-10 at 15:32 -0800, Manasi Navare wrote:
> On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> > Not validating the the mode rate against link rate results not pruning
> > invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> > support 4k @ 60Hz. But, we do not reject this mode currently.
> >
> > So, make use of the helpers in intel_dp in validate mode rates against
> > max. data rate of a configuration.
> >
> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 4 ++--
> > drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++++++++++-
> > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > 3 files changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 7a9e122..7a73e43 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> > return min(source_max, sink_max);
> > }
> >
> > -static int
> > +int
> > intel_dp_link_required(int pixel_clock, int bpp)
> > {
> > /* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
> > return (pixel_clock * bpp + 7) / 8;
> > }
> >
> > -static int
> > +int
> > intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> > {
> > /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 3ffbd69..38d2ce0 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -335,7 +335,17 @@ static enum drm_mode_status
> > intel_dp_mst_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> > {
> > + struct intel_connector *intel_connector = to_intel_connector(connector);
> > + struct intel_dp *intel_dp = intel_connector->mst_port;
> > int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > + int link_clock = intel_dp_max_link_rate(intel_dp);
> > + int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > + int bpp = 24; /* MST uses fixed bpp */
> > + int mode_rate;
> > + int link_max_data_rate;
>
> In the SST equivalent mode_valid function, this variable is named as
> max_rate, I think you should name it as max_rate as well for consistency.
> Other than that this looks good, we definitely need this for mode validation
> at an early stage.
>
> Regards
> Manasi
>
Well, one of the goals of Patch 1/2 is to reduce ambiguity that has led
to some confusing hacks. I prefer clarity over consistency and anyway
this variable is local to this function :)
-DK
> > +
> > + link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
> > + mode_rate = intel_dp_link_required(mode->clock, bpp);
> >
> > /* TODO - validate mode against available PBN for link */
> > if (mode->clock < 10000)
> > @@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
> > if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > return MODE_H_ILLEGAL;
> >
> > - if (mode->clock > max_dotclk)
> > + if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
> > return MODE_CLOCK_HIGH;
> >
> > return MODE_OK;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index c2f3863..313419d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > bool __intel_dp_read_desc(struct intel_dp *intel_dp,
> > struct intel_dp_desc *desc);
> > bool intel_dp_read_desc(struct intel_dp *intel_dp);
> > +int intel_dp_link_required(int pixel_clock, int bpp);
> > +int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> >
> > /* intel_dp_aux_backlight.c */
> > int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
> > --
> > 2.7.4
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
From: NeilBrown @ 2016-11-14 21:35 UTC (permalink / raw)
To: Mark Brown
Cc: Baolin Wang, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Lee Jones, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
In-Reply-To: <20161114120430.hpnetdedyofhlkad@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3323 bytes --]
On Mon, Nov 14 2016, Mark Brown wrote:
> On Mon, Nov 14, 2016 at 03:21:13PM +1100, NeilBrown wrote:
>> On Thu, Nov 10 2016, Baolin Wang wrote:
>
>> > Fourth, we need integrate all charger plugin/out
>> > event in one framework, not from extcon, maybe type-c in future.
>
>> Why not extcon? Given that a charger is connected by an external
>> connector, extcon seems like exactly the right thing to use.
>
>> Obviously extcon doesn't report the current that was negotiated, but
>> that is best kept separate. The battery charger can be advised of the
>> available current either via extcon or separately via the usb
>> subsystem. Don't conflate the two.
>
> Conflating the two seems like the whole point here. We're looking for
> something that sits between the power supply code and the USB code and
> tells the power supply code what it's allowed to do which is the result
> of a combination of physical cable detection and USB protocol. It seems
> reasonable that extcon drivers ought to be part of this but it doesn't
> seem like they are the whole story.
I don't think "between the power supply code and the USB code" is where
this thing sits. I think it sits inside the power-supply driver.
We already have extcon which sits between the phy and the power_supply
code, and the usb_notifier which sits between the USB code and the
power supply code. We don't need another go-between.
If we have extcon able to deliver reliable information about cable type,
and if with have the usb notifier able to deliver reliable information
about negotiated current, and if the power supply manager is able to
register with the correct extcon and the correct usb notifier, then the
power supply manager *could* handle all the notifications and make the
correct determinations and set the current limits itself. All this
could be done entirely internally, without the help of any new
subsystem.
Do you agree?
Clearly doing it that way would result in lots of code duplication and
would mean that each driver probably gets its own private set of bugs,
but it would be possible. Just undesirable.
So yes, it makes perfect to provide common code which handles the
registrations, and captures the events, and translates the different
events into current levels and feeds those back to the driver. This
isn't some new subsystem, this is just a resource, provided by a
library, that power drivers can allocate and initialize if the want to.
To quote myself:
> 5/ Now that all cable connection notifications are sent over extcon and
> all vbus_draw notifications are sent over the usb_phy notifier, write
> some support code that a power supply client can use to be told what
> power is available.
> e.g. a battery charger driver would call:
> register_power_client(.....)
> or similar, providing a phandle (or similar) for the usb phy and a
> function to call back when the available current changes (or maybe a
> work_struct containing the function pointer)
>
> register_power_client() would then register with extcon and separately
> with the usb_phy notifier. When the different events arrive it
> calculates what ranges of currents are expected and calls the
> call-back function with those details.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH v6 2/2] armv8/fsl-layerscape: fdt: fixup LS1043A rev1 MSI node
From: york sun @ 2016-11-14 21:36 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1477970547-28846-2-git-send-email-wenbin.song@nxp.com>
On 10/31/2016 08:35 PM, Wenbin song wrote:
> There are two types of msi node in kernel device tree, one is for
> LS1043A rev1.1 silicon, the other is for rev1.0.
This doesn't explain the difference between the two versions. I don't
see comments below either.
>
> According to revision number, fixup the msi node.
>
> Signed-off-by: Wenbin Song <wenbin.song@nxp.com>
> Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com>
> ---
> Change in v6:
> None
> Change in v5:
> Fixup the msi node used on rev1.0 when running on rev1.1.
> ---
> arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 3 +
> arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 115 ++++++++++++++++++++++++++++++
> 2 files changed, 118 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> index f415868..34ac867 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> @@ -139,4 +139,7 @@ config HAS_FEATURE_GIC4K_ALIGN
> bool
> default y if ARCH_LS1043A
>
> +config HAS_FEATURE_ENHANCED_MSI
> + bool
> + default y if ARCH_LS1043A
> endmenu
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> index 9936be1..e87ba19 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> @@ -194,6 +194,118 @@ static void fdt_fixup_gic(void *blob)
> }
> #endif
>
> +#ifdef CONFIG_HAS_FEATURE_ENHANCED_MSI
> +static int _fdt_fixup_msi_subnode(void *blob, int offset, const char *name,
> + int irq_0, int irq_1, int rev)
> +{
> + int err, sub_offset, len;
> + u32 tmp[4][3];
> +
> + sub_offset = fdt_subnode_offset(blob, offset, name);
> + if (offset < 0) {
> + printf("WARNING: fdt_subnode_offset can't find %s: %s\n",
> + name, fdt_strerror(sub_offset));
> + return 0;
> + }
> +
> + tmp[0][0] = cpu_to_fdt32(0x0);
> + tmp[0][1] = cpu_to_fdt32(irq_0);
> + tmp[0][2] = cpu_to_fdt32(0x4);
> +
> + if (rev > REV1_0) {
> + tmp[1][0] = cpu_to_fdt32(0x0);
> + tmp[1][1] = cpu_to_fdt32(irq_1);
> + tmp[1][2] = cpu_to_fdt32(0x4);
> + tmp[2][0] = cpu_to_fdt32(0x0);
> + tmp[2][1] = cpu_to_fdt32(irq_1 + 1);
> + tmp[2][2] = cpu_to_fdt32(0x4);
> + tmp[3][0] = cpu_to_fdt32(0x0);
> + tmp[3][1] = cpu_to_fdt32(irq_1 + 2);
> + tmp[3][2] = cpu_to_fdt32(0x4);
> + len = sizeof(tmp);
Looks like you are adding three more interrupts. Some comments here
would be nice.
> + } else {
> + len = sizeof(tmp[0]);
> + }
> +
> + err = fdt_setprop(blob, sub_offset, "interrupts", tmp, len);
> + if (err < 0) {
> + printf("WARNING: fdt_setprop can't set %s from node %s: %s\n",
> + "interrupts", name, fdt_strerror(err));
> + return 0;
> + }
> +
> + return 1;
> +}
> +
> +static int _fdt_fixup_pci_msi(void *blob, const char *name, int rev)
> +{
> + int offset, len, err;
> + void *p;
> + int val;
> + u32 tmp[4][8];
> +
> + offset = fdt_path_offset(blob, name);
> + if (offset < 0) {
> + printf("WARNING: fdt_path_offset can't find path %s: %s\n",
> + name, fdt_strerror(offset));
> + return 0;
> + }
> +
> + p = (char *)fdt_getprop(blob, offset, "interrupt-map", &len);
> + if (!p || len != sizeof(tmp)) {
Is the length check always accurate here?
> + printf("WARNING: fdt_getprop can't get %s from node %s\n",
> + "interrupt-map", name);
> + return 0;
> + }
> +
> + memcpy((char *)tmp, p, len);
> +
> + val = fdt32_to_cpu(tmp[0][6]);
> + if (rev > REV1_0) {
> + tmp[1][6] = cpu_to_fdt32(val + 1);
> + tmp[2][6] = cpu_to_fdt32(val + 2);
> + tmp[3][6] = cpu_to_fdt32(val + 3);
> + } else {
> + tmp[1][6] = cpu_to_fdt32(val);
> + tmp[2][6] = cpu_to_fdt32(val);
> + tmp[3][6] = cpu_to_fdt32(val);
> + }
> +
> + err = fdt_setprop(blob, offset, "interrupt-map", tmp, sizeof(tmp));
> + if (err < 0) {
> + printf("WARNING: fdt_setprop can't set %s from node %s: %s.\n",
> + "interrupt-map", name, fdt_strerror(err));
> + return 0;
> + }
> + return 1;
> +}
> +
> +/* Fixup msi to v1_0*/
> +
This comment is not accurate. You are fixing msi for both 1.0 and 1.1.
York
^ permalink raw reply
* [PATCH] can: spi: hi311x: fix semicolon.cocci warnings (fwd)
From: Julia Lawall @ 2016-11-14 21:36 UTC (permalink / raw)
Cc: wg, mkl, robh+dt, mark.rutland, linux-can, netdev, devicetree,
linux-kernel, Akshay Bhat, Akshay Bhat
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Akshay Bhat <akshay.bhat@timesys.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
It's a minor issue, but may as well fix it up now. The tree this code is
from is as follows:
url:
https://github.com/0day-ci/linux/commits/Akshay-Bhat/can-holt_hi311x-documen
t-device-tree-bindings/20161115-034509
:::::: branch date: 2 hours ago
:::::: commit date: 2 hours ago
hi311x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/spi/hi311x.c
+++ b/drivers/net/can/spi/hi311x.c
@@ -673,7 +673,7 @@ static irqreturn_t hi3110_can_ist(int ir
while (!(HI3110_STAT_RXFMTY &
hi3110_read(spi, HI3110_READ_STATF))) {
hi3110_hw_rx(spi);
- };
+ }
intf = hi3110_read(spi, HI3110_READ_INTF);
eflag = hi3110_read(spi, HI3110_READ_ERR);
^ permalink raw reply
* Re: [PATCH net-next 1/1] driver: macvlan: Replace integer number with bool value
From: David Miller @ 2016-11-14 21:36 UTC (permalink / raw)
To: fgao; +Cc: kaber, netdev, gfree.wind
In-Reply-To: <1479083059-12688-1-git-send-email-fgao@ikuai8.com>
From: fgao@ikuai8.com
Date: Mon, 14 Nov 2016 08:24:19 +0800
> From: Gao Feng <gfree.wind@gmail.com>
>
> The return value of function macvlan_addr_busy is used as bool value,
> so use bool value instead of integer number "1" and "0".
>
> Signed-off-by: Gao Feng <gfree.wind@gmail.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] can: spi: hi311x: fix semicolon.cocci warnings (fwd)
From: Julia Lawall @ 2016-11-14 21:36 UTC (permalink / raw)
To: Akshay Bhat
Cc: wg, mkl, robh+dt, mark.rutland, linux-can, netdev, devicetree,
linux-kernel, Akshay Bhat, Akshay Bhat
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Akshay Bhat <akshay.bhat@timesys.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
It's a minor issue, but may as well fix it up now. The tree this code is
from is as follows:
url:
https://github.com/0day-ci/linux/commits/Akshay-Bhat/can-holt_hi311x-documen
t-device-tree-bindings/20161115-034509
:::::: branch date: 2 hours ago
:::::: commit date: 2 hours ago
hi311x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/spi/hi311x.c
+++ b/drivers/net/can/spi/hi311x.c
@@ -673,7 +673,7 @@ static irqreturn_t hi3110_can_ist(int ir
while (!(HI3110_STAT_RXFMTY &
hi3110_read(spi, HI3110_READ_STATF))) {
hi3110_hw_rx(spi);
- };
+ }
intf = hi3110_read(spi, HI3110_READ_INTF);
eflag = hi3110_read(spi, HI3110_READ_ERR);
^ permalink raw reply
* Re: [PATCH -next] PCI: dra7xx: Add missing of_node_put() in dra7xx_pcie_init_irq_domain()
From: Heiko Stuebner @ 2016-11-14 21:37 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Kishon Vijay Abraham I, Wei Yongjun, Bjorn Helgaas, Wei Yongjun,
linux-omap, linux-pci, Shawn Lin, michal.simek, soren.brinkmann,
bharat.kumar.gogada, robh, Frank Rowand, devicetree
In-Reply-To: <20161114211928.GD9868@bhelgaas-glaptop.roam.corp.google.com>
Am Montag, 14. November 2016, 15:19:28 CET schrieb Bjorn Helgaas:
> [+cc Shawn, Heiko, Michal, Soren, Bharat, Rob H, Frank, devicetree@vger]
>
> On Sat, Nov 12, 2016 at 12:39:01PM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> >
> > On Saturday 12 November 2016 03:08 AM, Bjorn Helgaas wrote:
> > > On Mon, Oct 17, 2016 at 02:54:37PM +0000, Wei Yongjun wrote:
> > >> From: Wei Yongjun <weiyongjun1@huawei.com>
> > >>
> > >> This node pointer is returned by of_get_next_child() with refcount
> > >> incremented in this function. of_node_put() on it before exitting
> > >> this function on error.
> > >>
> > >> This is detected by Coccinelle semantic patch.
> > >>
> > >> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> > >
> > > Kishon, this looks correct to me, so I applied it to pci/host-dra7xx for
> > > v4.10. Let me know if you have any issue with it.
> > >
> > >> ---
> > >>
> > >> drivers/pci/host/pci-dra7xx.c | 1 +
> > >> 1 file changed, 1 insertion(+)
> > >>
> > >> diff --git a/drivers/pci/host/pci-dra7xx.c
> > >> b/drivers/pci/host/pci-dra7xx.c
> > >> index 9595fad..79297e9 100644
> > >> --- a/drivers/pci/host/pci-dra7xx.c
> > >> +++ b/drivers/pci/host/pci-dra7xx.c
> > >> @@ -177,6 +177,7 @@ static int dra7xx_pcie_init_irq_domain(struct
> > >> pcie_port *pp)> >>
> > >> &intx_domain_ops, pp);
> > >>
> > >> if (!pp->irq_domain) {
> > >>
> > >> dev_err(dev, "Failed to get a INTx IRQ domain\n");
> > >>
> > >> + of_node_put(pcie_intc_node);
> >
> > I think of_node_put should be used for both the error case and non-error
> > case.
> Hmm, OK. I don't know what the rules are. Certainly if we made these
> drivers modular, I don't think we'd want to leak these references
> every time we unload/reload the module. Should we do the put
> immediately here, or in the module remove path, or ...?
>
> Adding other driver and DT folks for comment.
I think the function above (dra7xx_pcie_init_irq_domain) can do the
of_node_put at its end in all cases as suggested by Kishon.
of_get_next_child() will increment the refcount
irq_domain_add_linear()
__irq_domain_add() also increments the refcount
irq_domain_remove() will decrement the refcount
So it should be safe to decrement the refcount in
dra7xx_pcie_init_irq_domain() in all cases as the irq-domain internals will
always keep it above 1 as long as the node is used.
Heiko
^ permalink raw reply
* Out-of-tree module build against yocto kernel
From: Ed @ 2016-11-14 21:38 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]
I want to build an out-of-tree kernel module against my Yocto-generated
kernel (cross-compiled, not on the target).
I know that I can modify the hello-mod recipe to build it alongside the
Yocto image, but I'd strongly prefer not to; it's not a workflow that's
conducive to rapid iteration during development & test.
I've tried building against the kernel in
<TMP>/work-shared/<MACHINE>/kernel-source, to no avail. While I don't
understand everytihng that's going on, I suspect it has something to do
with how Yocto organizes kernel build artifacts (autoconf headers,
Module.symvers, conf stuff).
I've also tried building a SDK. By default that didn't seem to include
kernel headers, so I added kernel-devsrc to TOOLCHAIN_TARGET_TASK in
populate_sdk_base.bbclass. That seemed to get me kernel source w/ the SDK,
but I still haven't been able to successfully build against it.
A great deal of my troubleshooting has been driven by the a 2013 discussion
on this list that appeared to end inconclusively:
https://lists.yoctoproject.org/pipermail/yocto/2013-January/011564.html
Am I going about this in the right way? Am I just missing some
configuration/setup steps, or am I going about this all wrong? Everything
I'm trying feels clunky and hack-ish.
--
Ed Laird
On two occasions I have been asked,—"Pray, Mr. Babbage, if you put into the
machine wrong figures, will the right answers come out?" ... I am not able
rightly to apprehend the kind of confusion of ideas that could provoke such
a question.
—Charles Babbage, Passages from the Life of a Philosopher
<http://en.wikipedia.org/wiki/Charles_Babbage>
[-- Attachment #2: Type: text/html, Size: 2032 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH v4 00/14] efi: x86: Add EFI hello world and loader support for x86
From: Simon Glass @ 2016-11-14 21:39 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1478533636-17577-1-git-send-email-sjg@chromium.org>
Resend attempt...
On 7 November 2016 at 08:47, Simon Glass <sjg@chromium.org> wrote:
> This series adds EFI loader support for x86. Since U-Boot already supports
> running as an EFI app (and as a payload) this is relatively
> straightforward, requiring just moving files into place and updating a few
> compiler flags.
>
> One problem with the EFI loader is that it lacks even rudimentary test
> support within U-Boot. At present the only way to test it is to boot an
> EFI application. As a step towards correcting this, this series also adds
> support for a 'hello world' test program which can be used to make sure
> that EFI loader support works correctly on a supported architecture. It is
> only a very simple program (it makes just two API calls!) but it does
> provide a sanity check and can be expanded as needed.
>
> No attempt is made to create a pytest with this, but it should be fairly
> straightforward to do so.
>
> Changes in v4:
> - Move hello world test program into new patch
> - Add new patch to add EFI app support
> - Add new patch to add EFI app support on aarch64
> - Use the build-generated 'hello world' program instead of a binary blob
> - Add new patch to adjust EFI files support efi_loader
> - Drop the binary 'hello world' program
>
> Changes in v3:
> - Include a link to the program instead of adding it to the tree
> - Fix several typos
> - Align backslashes to the same column
>
> Changes in v2:
> - Add new patch to tidy up selection of building the EFI stub
> - Remove EFI support from README.x86 TODO list
>
> Simon Glass (14):
> x86: Correct a build warning in x86 tables
> efi: Correct cache flush alignment
> efi: Fix debug message address format
> x86: Tidy up selection of building the EFI stub
> efi: Makefile: Export variables for use with EFI
> efi: Add support for a hello world test program
> elf: arm: Add a few ARM relocation types
> efi: arm: Add EFI app support
> efi: arm: Add aarch64 EFI app support
> efi: arm: Enable the hello world test program
> x86: Move efi .lds files into the 'lib' directory
> x86: Move efi .S files into the 'lib' directory
> efi: x86: Adjust EFI files support efi_loader
> x86: Enable EFI loader support
>
> Makefile | 11 +-
> arch/arm/config.mk | 7 ++
> arch/arm/cpu/armv8/config.mk | 4 +
> arch/arm/lib/Makefile | 10 ++
> arch/arm/lib/crt0_aarch64_efi.S | 135 ++++++++++++++++++++
> arch/arm/lib/crt0_arm_efi.S | 138 +++++++++++++++++++++
> arch/arm/lib/elf_aarch64_efi.lds | 70 +++++++++++
> arch/arm/lib/elf_arm_efi.lds | 70 +++++++++++
> arch/arm/lib/reloc_aarch64_efi.c | 87 +++++++++++++
> arch/arm/lib/reloc_arm_efi.c | 66 ++++++++++
> arch/arm/lib/relocate.S | 3 +-
> arch/arm/lib/relocate_64.S | 3 +-
> arch/x86/config.mk | 20 ++-
> arch/x86/lib/Makefile | 23 ++++
> .../lib/{efi/crt0-efi-ia32.S => crt0_ia32_efi.S} | 0
> .../{efi/crt0-efi-x86_64.S => crt0_x86_64_efi.S} | 0
> arch/x86/lib/efi/Makefile | 18 ---
> arch/x86/{cpu/efi => lib}/elf_ia32_efi.lds | 2 -
> arch/x86/{cpu/efi => lib}/elf_x86_64_efi.lds | 2 -
> .../x86/lib/{efi/reloc_ia32.c => reloc_ia32_efi.c} | 0
> .../lib/{efi/reloc_x86_64.c => reloc_x86_64_efi.c} | 0
> arch/x86/lib/tables.c | 2 +
> cmd/Kconfig | 10 ++
> cmd/bootefi.c | 29 +++--
> configs/efi-x86_defconfig | 1 +
> configs/qemu-x86_efi_payload64_defconfig | 1 +
> configs/stm32f429-discovery_defconfig | 1 +
> doc/README.efi | 22 ++++
> doc/README.x86 | 1 -
> include/asm-generic/sections.h | 2 +
> include/efi.h | 7 +-
> include/elf.h | 13 ++
> lib/efi/Makefile | 4 +-
> lib/efi_loader/Kconfig | 2 +-
> lib/efi_loader/Makefile | 4 +
> lib/efi_loader/efi_image_loader.c | 3 +-
> lib/efi_loader/helloworld.c | 24 ++++
> scripts/Makefile.lib | 33 +++++
> 38 files changed, 787 insertions(+), 41 deletions(-)
> create mode 100644 arch/arm/lib/crt0_aarch64_efi.S
> create mode 100644 arch/arm/lib/crt0_arm_efi.S
> create mode 100644 arch/arm/lib/elf_aarch64_efi.lds
> create mode 100644 arch/arm/lib/elf_arm_efi.lds
> create mode 100644 arch/arm/lib/reloc_aarch64_efi.c
> create mode 100644 arch/arm/lib/reloc_arm_efi.c
> rename arch/x86/lib/{efi/crt0-efi-ia32.S => crt0_ia32_efi.S} (100%)
> rename arch/x86/lib/{efi/crt0-efi-x86_64.S => crt0_x86_64_efi.S} (100%)
> rename arch/x86/{cpu/efi => lib}/elf_ia32_efi.lds (98%)
> rename arch/x86/{cpu/efi => lib}/elf_x86_64_efi.lds (98%)
> rename arch/x86/lib/{efi/reloc_ia32.c => reloc_ia32_efi.c} (100%)
> rename arch/x86/lib/{efi/reloc_x86_64.c => reloc_x86_64_efi.c} (100%)
> create mode 100644 lib/efi_loader/helloworld.c
>
> --
> 2.8.0.rc3.226.g39d4020
>
^ permalink raw reply
* Re: [PATCH 13/15] PCI/ASPM: use permission-specific DEVICE_ATTR variants
From: Bjorn Helgaas @ 2016-11-14 21:40 UTC (permalink / raw)
To: Julia Lawall; +Cc: Bjorn Helgaas, kernel-janitors, linux-pci, linux-kernel
In-Reply-To: <1477769829-22230-14-git-send-email-Julia.Lawall@lip6.fr>
On Sat, Oct 29, 2016 at 09:37:07PM +0200, Julia Lawall wrote:
> Use DEVICE_ATTR_RW for read-write attributes. This simplifies the
> source code, improves readbility, and reduces the chance of
> inconsistencies.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @rw@
> declarer name DEVICE_ATTR;
> identifier x,x_show,x_store;
> @@
>
> DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
>
> @script:ocaml@
> x << rw.x;
> x_show << rw.x_show;
> x_store << rw.x_store;
> @@
>
> if not (x^"_show" = x_show && x^"_store" = x_store)
> then Coccilib.include_match false
>
> @@
> declarer name DEVICE_ATTR_RW;
> identifier rw.x,rw.x_show,rw.x_store;
> @@
>
> - DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
> + DEVICE_ATTR_RW(x);
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
I applied this to pci/aspm to follow the herd, although it looks
pretty similar to the ill-fated "Replace numeric parameter like 0444
with macro" series (http://lwn.net/Articles/696229/). Maybe this is
different because everybody except me knows what ATTR_RW means? To
me, "0644" contained more information than "_RW" does.
I do certainly like the removal of the "_show" and "_store"
redundancy.
> ---
> drivers/pci/pcie/aspm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index 0ec649d..3b14d9e 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -886,8 +886,8 @@ static ssize_t clk_ctl_store(struct device *dev,
> return n;
> }
>
> -static DEVICE_ATTR(link_state, 0644, link_state_show, link_state_store);
> -static DEVICE_ATTR(clk_ctl, 0644, clk_ctl_show, clk_ctl_store);
> +static DEVICE_ATTR_RW(link_state);
> +static DEVICE_ATTR_RW(clk_ctl);
>
> static char power_group[] = "power";
> void pcie_aspm_create_sysfs_dev_files(struct pci_dev *pdev)
>
^ permalink raw reply
* Re: [PATCH 13/15] PCI/ASPM: use permission-specific DEVICE_ATTR variants
From: Bjorn Helgaas @ 2016-11-14 21:40 UTC (permalink / raw)
To: Julia Lawall; +Cc: Bjorn Helgaas, kernel-janitors, linux-pci, linux-kernel
In-Reply-To: <1477769829-22230-14-git-send-email-Julia.Lawall@lip6.fr>
On Sat, Oct 29, 2016 at 09:37:07PM +0200, Julia Lawall wrote:
> Use DEVICE_ATTR_RW for read-write attributes. This simplifies the
> source code, improves readbility, and reduces the chance of
> inconsistencies.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @rw@
> declarer name DEVICE_ATTR;
> identifier x,x_show,x_store;
> @@
>
> DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
>
> @script:ocaml@
> x << rw.x;
> x_show << rw.x_show;
> x_store << rw.x_store;
> @@
>
> if not (x^"_show" = x_show && x^"_store" = x_store)
> then Coccilib.include_match false
>
> @@
> declarer name DEVICE_ATTR_RW;
> identifier rw.x,rw.x_show,rw.x_store;
> @@
>
> - DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
> + DEVICE_ATTR_RW(x);
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
I applied this to pci/aspm to follow the herd, although it looks
pretty similar to the ill-fated "Replace numeric parameter like 0444
with macro" series (http://lwn.net/Articles/696229/). Maybe this is
different because everybody except me knows what ATTR_RW means? To
me, "0644" contained more information than "_RW" does.
I do certainly like the removal of the "_show" and "_store"
redundancy.
> ---
> drivers/pci/pcie/aspm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index 0ec649d..3b14d9e 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -886,8 +886,8 @@ static ssize_t clk_ctl_store(struct device *dev,
> return n;
> }
>
> -static DEVICE_ATTR(link_state, 0644, link_state_show, link_state_store);
> -static DEVICE_ATTR(clk_ctl, 0644, clk_ctl_show, clk_ctl_store);
> +static DEVICE_ATTR_RW(link_state);
> +static DEVICE_ATTR_RW(clk_ctl);
>
> static char power_group[] = "power";
> void pcie_aspm_create_sysfs_dev_files(struct pci_dev *pdev)
>
^ permalink raw reply
* Re: [PATCH net] net: stmmac: Fix lack of link transition for fixed PHYs
From: David Miller @ 2016-11-14 21:40 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, peppe.cavallaro, alexandre.torgue, linux-kernel
In-Reply-To: <20161114015036.6926-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sun, 13 Nov 2016 17:50:35 -0800
> Commit 52f95bbfcf72 ("stmmac: fix adjust link call in case of a switch
> is attached") added some logic to avoid polling the fixed PHY and
> therefore invoking the adjust_link callback more than once, since this
> is a fixed PHY and link events won't be generated.
>
> This works fine the first time, because we start with phydev->irq =
> PHY_POLL, so we call adjust_link, then we set phydev->irq =
> PHY_IGNORE_INTERRUPT and we stop polling the PHY.
>
> Now, if we called ndo_close(), which calls both phy_stop() and does an
> explicit netif_carrier_off(), we end up with a link down. Upon calling
> ndo_open() again, despite starting the PHY state machine, we have
> PHY_IGNORE_INTERRUPT set, and we generate no link event at all, so the
> link is permanently down.
>
> 52f95bbfcf72 ("stmmac: fix adjust link call in case of a switch is attached")
I added the missing "Fixes: " here.
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied and queued up for -stable, thanks Florian.
^ permalink raw reply
* Re: [PATCH net-next] mdio: Demote print from info to debug in mdio_driver_register
From: David Miller @ 2016-11-14 21:41 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew
In-Reply-To: <20161114030117.25169-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sun, 13 Nov 2016 19:01:17 -0800
> While it is useful to know which MDIO driver is being registered, demote
> the pr_info() to a pr_debug().
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 2/3] cpuidle: allow setting deepest idle
From: Rafael J. Wysocki @ 2016-11-14 21:42 UTC (permalink / raw)
To: Jacob Pan
Cc: Peter Zijlstra, Ingo Molnar, Thomas Gleixner, LKML, Linux PM,
Arjan van de Ven, Srinivas Pandruvada, Len Brown, Rafael Wysocki,
Eduardo Valentin, Zhang Rui, Petr Mladek,
Sebastian Andrzej Siewior
In-Reply-To: <1479149278-12418-3-git-send-email-jacob.jun.pan@linux.intel.com>
On Monday, November 14, 2016 10:47:57 AM Jacob Pan wrote:
> When idle injection is used to cap power, we need to override
> governor's choice of idle states. This patch allows caller to select
> the deepest idle state on a CPU therefore achieve the maximum
> potential power saving.
>
> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> ---
> drivers/cpuidle/cpuidle.c | 11 +++++++++++
> include/linux/cpuidle.h | 4 +++-
> kernel/sched/idle.c | 3 +++
> 3 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index c73207a..887a52a 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -97,6 +97,17 @@ static int find_deepest_state(struct cpuidle_driver *drv,
> return ret;
> }
>
> +/* Set the current cpu to use the deepest idle state, override governors */
> +void cpuidle_use_deepest_state(bool enable)
> +{
> + struct cpuidle_device *dev;
> +
> + preempt_disable();
> + dev = cpuidle_get_device();
> + dev->use_deepest_state = enable;
> + preempt_enable();
> +}
> +
> #ifdef CONFIG_SUSPEND
> /**
> * cpuidle_find_deepest_state - Find the deepest available idle state.
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index bb31373..7f93c63 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -74,6 +74,7 @@ struct cpuidle_state {
> struct cpuidle_device {
> unsigned int registered:1;
> unsigned int enabled:1;
> + unsigned int use_deepest_state:1;
> unsigned int cpu;
>
> int last_residency;
> @@ -192,11 +193,12 @@ static inline struct cpuidle_driver *cpuidle_get_cpu_driver(
> static inline struct cpuidle_device *cpuidle_get_device(void) {return NULL; }
> #endif
>
> -#if defined(CONFIG_CPU_IDLE) && defined(CONFIG_SUSPEND)
> +#if defined(CONFIG_CPU_IDLE)
#ifdef CONFIG_CPU_IDLE
would be more ususal.
> extern int cpuidle_find_deepest_state(struct cpuidle_driver *drv,
> struct cpuidle_device *dev);
> extern int cpuidle_enter_freeze(struct cpuidle_driver *drv,
> struct cpuidle_device *dev);
> +extern void cpuidle_use_deepest_state(bool enable);
> #else
> static inline int cpuidle_find_deepest_state(struct cpuidle_driver *drv,
> struct cpuidle_device *dev)
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index cb6442f..9e80f32 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -173,6 +173,9 @@ static void cpuidle_idle_call(void)
>
> next_state = cpuidle_find_deepest_state(drv, dev);
> call_cpuidle(drv, dev, next_state);
> + } else if (dev->use_deepest_state) {
> + next_state = cpuidle_find_deepest_state(drv, dev);
> + call_cpuidle(drv, dev, next_state);
> } else {
> /*
> * Ask the cpuidle framework to choose a convenient idle state.
I would arrange the code slightly differently here:
if (idle_should_freeze() || dev->use_deepest_state) {
if (idle_should_freeze()) {
entered_state = cpuidle_enter_freeze(drv, dev);
if (entered_state > 0) {
local_irq_enable();
goto exit_idle;
}
}
next_state = cpuidle_find_deepest_state(drv, dev);
call_cpuidle(drv, dev, next_state);
} else {
This way you'd avoid the ugly code duplication and the extra
dev->use_deepest_state branch in the most frequent case. I guess you could
take the unlikely() thing away from idle_should_freeze() and use it directly
here too.
Thanks,
Rafael
^ permalink raw reply
* [PATCH nft] mnl: use nftnl_set_elems_nlmsg_build_payload_iter() when deleting elements
From: Pablo Neira Ayuso @ 2016-11-14 21:41 UTC (permalink / raw)
To: netfilter-devel
Otherwise, nft crashes when deleting a very large number of elements.
*** stack smashing detected ***: nft terminated
Segmentation fault
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
src/mnl.c | 25 +++++++++++--------------
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/src/mnl.c b/src/mnl.c
index 52875f4a16da..137ecf0d1e01 100644
--- a/src/mnl.c
+++ b/src/mnl.c
@@ -867,8 +867,9 @@ static int set_elem_cb(const struct nlmsghdr *nlh, void *data)
return MNL_CB_OK;
}
-int mnl_nft_setelem_batch_add(struct nftnl_set *nls, unsigned int flags,
- uint32_t seqnum)
+static int mnl_nft_setelem_batch(struct nftnl_set *nls,
+ enum nf_tables_msg_types cmd,
+ unsigned int flags, uint32_t seqnum)
{
struct nlmsghdr *nlh;
struct nftnl_set_elems_iter *iter;
@@ -880,8 +881,7 @@ int mnl_nft_setelem_batch_add(struct nftnl_set *nls, unsigned int flags,
do {
nlh = nftnl_set_elem_nlmsg_build_hdr(nftnl_batch_buffer(batch),
- NFT_MSG_NEWSETELEM,
- nftnl_set_get_u32(nls, NFTNL_SET_FAMILY),
+ cmd, nftnl_set_get_u32(nls, NFTNL_SET_FAMILY),
NLM_F_CREATE | flags, seqnum);
ret = nftnl_set_elems_nlmsg_build_payload_iter(nlh, iter);
mnl_nft_batch_continue();
@@ -892,19 +892,16 @@ int mnl_nft_setelem_batch_add(struct nftnl_set *nls, unsigned int flags,
return 0;
}
-int mnl_nft_setelem_batch_del(struct nftnl_set *nls, unsigned int flags,
+int mnl_nft_setelem_batch_add(struct nftnl_set *nls, unsigned int flags,
uint32_t seqnum)
{
- struct nlmsghdr *nlh;
-
- nlh = nftnl_set_elem_nlmsg_build_hdr(nftnl_batch_buffer(batch),
- NFT_MSG_DELSETELEM,
- nftnl_set_get_u32(nls, NFTNL_SET_FAMILY),
- 0, seqnum);
- nftnl_set_elems_nlmsg_build_payload(nlh, nls);
- mnl_nft_batch_continue();
+ return mnl_nft_setelem_batch(nls, NFT_MSG_NEWSETELEM, flags, seqnum);
+}
- return 0;
+int mnl_nft_setelem_batch_del(struct nftnl_set *nls, unsigned int flags,
+ uint32_t seqnum)
+{
+ return mnl_nft_setelem_batch(nls, NFT_MSG_DELSETELEM, flags, seqnum);
}
int mnl_nft_setelem_get(struct mnl_socket *nf_sock, struct nftnl_set *nls)
--
2.1.4
^ permalink raw reply related
* [PATCH v2 1/2] drm/dp/i915: Fix DP link rate math
From: Dhinakaran Pandiyan @ 2016-11-14 21:42 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula, Dhinakaran Pandiyan
We store DP link rates as link clock frequencies in kHz, just like all
other clock values. But, DP link rates in the DP Spec. are expressed in
Gbps/lane, which seems to have led to some confusion.
E.g., for HBR2
Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 2160000 kBps
where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion
Using link clock frequency, like we do
Max. data rate = 540000 kHz * 4 lanes = 2160000 kSymbols/s
Because, each symbol has 8 bit of data, this is 2160000 kBps
and there is no need to account for channel encoding here.
But, currently we do 540000 kHz * 4 lanes * (8/10) = 1728000 kBps
Similarly, while computing the required link bandwidth for a mode,
there is a mysterious 1/10 term.
This should simply be pixel_clock kHz * (bpp/8) to give the final result in
kBps
v2: Changed to DIV_ROUND_UP() and comment changes (Ville)
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
---
drivers/gpu/drm/i915/intel_dp.c | 35 +++++++++++++++--------------------
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8f313c1..0c5d4bd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
return min(source_max, sink_max);
}
-/*
- * The units on the numbers in the next two are... bizarre. Examples will
- * make it clearer; this one parallels an example in the eDP spec.
- *
- * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
- *
- * 270000 * 1 * 8 / 10 == 216000
- *
- * The actual data capacity of that configuration is 2.16Gbit/s, so the
- * units are decakilobits. ->clock in a drm_display_mode is in kilohertz -
- * or equivalently, kilopixels per second - so for 1680x1050R it'd be
- * 119000. At 18bpp that's 2142000 kilobits per second.
- *
- * Thus the strange-looking division by 10 in intel_dp_link_required, to
- * get the result in decakilobits instead of kilobits.
- */
-
static int
intel_dp_link_required(int pixel_clock, int bpp)
{
- return (pixel_clock * bpp + 9) / 10;
+ /* pixel_clock is in kHz, divide bpp by 8 for bit to Byte conversion */
+ return DIV_ROUND_UP(pixel_clk * bpp, 8);
}
static int
intel_dp_max_data_rate(int max_link_clock, int max_lanes)
{
- return (max_link_clock * max_lanes * 8) / 10;
+ /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
+ * link rate that is generally expressed in Gbps. Since, 8 bits of data
+ * is transmitted every LS_Clk per lane, there is no need to account for
+ * the channel encoding that is done in the PHY layer here.
+ */
+
+ return max_link_clock * max_lanes;
}
static int
@@ -3573,7 +3563,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (val == 0)
break;
- /* Value read is in kHz while drm clock is saved in deca-kHz */
+ /* Value read multiplied by 200kHz gives the per-lane
+ * link rate in kHz. The source rates are, however,
+ * stored in terms of LS_Clk kHz. The full conversion
+ * back to symbols is
+ * (val * 200kHz)*(8/10 ch. encoding)*(1/8 bit to Byte)
+ */
intel_dp->sink_rates[i] = (val * 200) / 10;
}
intel_dp->num_sink_rates = i;
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PATCH v2 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
From: Dhinakaran Pandiyan @ 2016-11-14 21:42 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula, Dhinakaran Pandiyan
In-Reply-To: <1479159735-29364-1-git-send-email-dhinakaran.pandiyan@intel.com>
Not validating the mode rate against max. link rate results in not pruning
invalid modes. For e.g, a HBR2 5.4 Gbps 2-lane configuration does not
support 4k@60Hz. But, we do not reject this mode.
So, make use of the helpers in intel_dp to validate mode data rate against
max. link data rate of a configuration.
v2: Renamed mode data rate local variable to be more explanatory.
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++++++++++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0c5d4bd..a7393e8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
return min(source_max, sink_max);
}
-static int
+int
intel_dp_link_required(int pixel_clock, int bpp)
{
/* pixel_clock is in kHz, divide bpp by 8 for bit to Byte conversion */
return DIV_ROUND_UP(pixel_clk * bpp, 8);
}
-static int
+int
intel_dp_max_data_rate(int max_link_clock, int max_lanes)
{
/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3ffbd69..2c557d9 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -335,7 +335,17 @@ static enum drm_mode_status
intel_dp_mst_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct intel_dp *intel_dp = intel_connector->mst_port;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
+ int link_clock = intel_dp_max_link_rate(intel_dp);
+ int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
+ int bpp = 24; /* MST uses fixed bpp */
+ int mode_data_rate;
+ int link_max_data_rate;
+
+ mode_data_rate = intel_dp_link_required(mode->clock, bpp);
+ link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
/* TODO - validate mode against available PBN for link */
if (mode->clock < 10000)
@@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_H_ILLEGAL;
- if (mode->clock > max_dotclk)
+ if (mode_data_rate > link_max_data_rate || mode->clock > max_dotclk)
return MODE_CLOCK_HIGH;
return MODE_OK;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c2f3863..313419d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
bool __intel_dp_read_desc(struct intel_dp *intel_dp,
struct intel_dp_desc *desc);
bool intel_dp_read_desc(struct intel_dp *intel_dp);
+int intel_dp_link_required(int pixel_clock, int bpp);
+int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
/* intel_dp_aux_backlight.c */
int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [Buildroot] [PATCH] openjpeg: security bump to version 2.1.2
From: Baruch Siach @ 2016-11-14 21:43 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161114223404.7c3b88be@free-electrons.com>
Hi Thomas,
On Mon, Nov 14, 2016 at 10:34:04PM +0100, Thomas Petazzoni wrote:
> On Mon, 14 Nov 2016 22:47:43 +0200, Baruch Siach wrote:
> > See CHANGELOG.md for the full list of fixes, including security issues.
> >
> > See CVE number lists at [1] and [2].
> >
> > [1] http://advisories.mageia.org/MGASA-2016-0362.html
> > [2] https://lists.fedoraproject.org/archives/list/package-announce at lists.fedoraproject.org/thread/HPMDEUIMHTLKMHELDL4F4HZ7X4Y34JEB/
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> > package/openjpeg/openjpeg.hash | 2 +-
> > package/openjpeg/openjpeg.mk | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
>
> Applied to master, thanks.
I mistakenly created this patch against -next. The newly added patches in
master don't apply to this version. I'll post a fix.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH] cpufreq: Avoid a couple of races related to cpufreq_cpu_get()
From: Rafael J. Wysocki @ 2016-11-14 21:51 UTC (permalink / raw)
To: Linux PM list
Cc: Linux Kernel Mailing List, Viresh Kumar, Srinivas Pandruvada
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The cpumask_test_cpu() check in cpufreq_cpu_get_raw() is sort of
pointless, because it may be racy with respect to CPU online/offline
which sets/clears the policy->cpus mask.
For this reason, it is better to reserve cpufreq_cpu_get_raw() for
the ondemand governor, which calls it for online CPUs only with CPU
online/offline locked anyway, and move the cpumask_test_cpu() up the
call chain.
Moreover, the callers of cpufreq_cpu_get() that really care about
avoiding races with CPU online/offline should better carry out that
check under policy->rwsem.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/cpufreq/cpufreq.c | 46 +++++++++++++++++++++++++++++++---------------
1 file changed, 31 insertions(+), 15 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -65,6 +65,12 @@ static struct cpufreq_driver *cpufreq_dr
static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
static DEFINE_RWLOCK(cpufreq_driver_lock);
+struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
+{
+ return per_cpu(cpufreq_cpu_data, cpu);
+}
+EXPORT_SYMBOL_GPL(cpufreq_cpu_get_raw);
+
/* Flag to suspend/resume CPUFreq governors */
static bool cpufreq_suspended;
@@ -192,19 +198,12 @@ int cpufreq_generic_init(struct cpufreq_
}
EXPORT_SYMBOL_GPL(cpufreq_generic_init);
-struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu)
-{
- struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
-
- return policy && cpumask_test_cpu(cpu, policy->cpus) ? policy : NULL;
-}
-EXPORT_SYMBOL_GPL(cpufreq_cpu_get_raw);
-
unsigned int cpufreq_generic_get(unsigned int cpu)
{
- struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
+ struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
- if (!policy || IS_ERR(policy->clk)) {
+ if (!policy || !cpumask_test_cpu(cpu, policy->cpus) ||
+ IS_ERR(policy->clk)) {
pr_err("%s: No %s associated to cpu: %d\n",
__func__, policy ? "clk" : "policy", cpu);
return 0;
@@ -240,7 +239,7 @@ struct cpufreq_policy *cpufreq_cpu_get(u
if (cpufreq_driver) {
/* get the CPU */
- policy = cpufreq_cpu_get_raw(cpu);
+ policy = per_cpu(cpufreq_cpu_data, cpu);
if (policy)
kobject_get(&policy->kobj);
}
@@ -1328,7 +1327,7 @@ static int cpufreq_offline(unsigned int
pr_debug("%s: unregistering CPU %u\n", __func__, cpu);
- policy = cpufreq_cpu_get_raw(cpu);
+ policy = per_cpu(cpufreq_cpu_data, cpu);
if (!policy) {
pr_debug("%s: No cpu_data found\n", __func__);
return 0;
@@ -1455,7 +1454,9 @@ unsigned int cpufreq_quick_get(unsigned
policy = cpufreq_cpu_get(cpu);
if (policy) {
- ret_freq = policy->cur;
+ if (cpumask_test_cpu(cpu, policy->cpus))
+ ret_freq = policy->cur;
+
cpufreq_cpu_put(policy);
}
@@ -1475,7 +1476,9 @@ unsigned int cpufreq_quick_get_max(unsig
unsigned int ret_freq = 0;
if (policy) {
- ret_freq = policy->max;
+ if (cpumask_test_cpu(cpu, policy->cpus))
+ ret_freq = policy->max;
+
cpufreq_cpu_put(policy);
}
@@ -1526,7 +1529,10 @@ unsigned int cpufreq_get(unsigned int cp
if (policy) {
down_read(&policy->rwsem);
- ret_freq = __cpufreq_get(policy);
+
+ if (cpumask_test_cpu(cpu, policy->cpus))
+ ret_freq = __cpufreq_get(policy);
+
up_read(&policy->rwsem);
cpufreq_cpu_put(policy);
@@ -2142,6 +2148,11 @@ int cpufreq_get_policy(struct cpufreq_po
if (!cpu_policy)
return -EINVAL;
+ if (!cpumask_test_cpu(cpu, policy->cpus)) {
+ cpufreq_cpu_put(cpu_policy);
+ return -EINVAL;
+ }
+
memcpy(policy, cpu_policy, sizeof(*policy));
cpufreq_cpu_put(cpu_policy);
@@ -2265,6 +2276,11 @@ int cpufreq_update_policy(unsigned int c
down_write(&policy->rwsem);
+ if (!cpumask_test_cpu(cpu, policy->cpus)) {
+ ret = -ENODEV;
+ goto unlock;
+ }
+
pr_debug("updating policy for CPU %u\n", cpu);
memcpy(&new_policy, policy, sizeof(*policy));
new_policy.min = policy->user_policy.min;
^ permalink raw reply
* Re: [patch net] mlxsw: spectrum_router: Flush FIB tables during fini
From: David Miller @ 2016-11-14 21:46 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz
In-Reply-To: <1479119192-1545-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 14 Nov 2016 11:26:32 +0100
> From: Ido Schimmel <idosch@mellanox.com>
>
> Since commit b45f64d16d45 ("mlxsw: spectrum_router: Use FIB notifications
> instead of switchdev calls") we reflect to the device the entire FIB
> table and not only FIBs that point to netdevs created by the driver.
>
> During module removal, FIBs of the second type are removed following
> NETDEV_UNREGISTER events sent. The other FIBs are still present in both
> the driver's cache and the device's table.
>
> Fix this by iterating over all the FIB tables in the device and flush
> them. There's no need to take locks, as we're the only writer.
>
> Fixes: b45f64d16d45 ("mlxsw: spectrum_router: Use FIB notifications instead of switchdev calls")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks Jiri.
^ permalink raw reply
* [PATCH] devshell: list commands when throwing NoSupportedTerminals
From: Stephano Cetola @ 2016-11-14 21:45 UTC (permalink / raw)
To: openembedded-core
When attempting to run devshell, if no terminal is available, the
error being thrown was not very specific. This adds a list of
commands that failed, informing the user of what they can install to
fix the error.
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
---
meta/classes/terminal.bbclass | 7 +++++--
meta/lib/oe/terminal.py | 15 ++++++++++++---
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/meta/classes/terminal.bbclass b/meta/classes/terminal.bbclass
index a94f755..5cfc7ac 100644
--- a/meta/classes/terminal.bbclass
+++ b/meta/classes/terminal.bbclass
@@ -88,8 +88,11 @@ def oe_terminal(command, title, d):
try:
oe.terminal.spawn_preferred(command, title, None, d)
- except oe.terminal.NoSupportedTerminals:
- bb.fatal('No valid terminal found, unable to open devshell')
+ except oe.terminal.NoSupportedTerminals as nosup:
+ cmds = '\n\t'.join(nosup.terms).replace("{command}",
+ "do_terminal").replace("{title}", title)
+ bb.fatal('No valid terminal found, unable to open devshell.\n' +
+ 'Tried the following commands:\n\t%s' % cmds)
except oe.terminal.ExecutionError as exc:
bb.fatal('Unable to spawn terminal %s: %s' % (terminal, exc))
diff --git a/meta/lib/oe/terminal.py b/meta/lib/oe/terminal.py
index 7446c44..e772a37 100644
--- a/meta/lib/oe/terminal.py
+++ b/meta/lib/oe/terminal.py
@@ -11,7 +11,8 @@ class UnsupportedTerminal(Exception):
pass
class NoSupportedTerminals(Exception):
- pass
+ def __init__(self, terms):
+ self.terms = terms
class Registry(oe.classutils.ClassRegistry):
@@ -191,7 +192,7 @@ class Tmux(Terminal):
logger.warn(msg)
class Custom(Terminal):
- command = 'false' # This is a placeholder
+ command = None # This is a placeholder
priority = 3
def __init__(self, sh_cmd, title=None, env=None, d=None):
@@ -209,6 +210,14 @@ class Custom(Terminal):
def prioritized():
return Registry.prioritized()
+def get_cmd_list():
+ terms = Registry.prioritized()
+ cmds = []
+ for term in terms:
+ if term.command:
+ cmds.append(term.command)
+ return cmds
+
def spawn_preferred(sh_cmd, title=None, env=None, d=None):
"""Spawn the first supported terminal, by priority"""
for terminal in prioritized():
@@ -218,7 +227,7 @@ def spawn_preferred(sh_cmd, title=None, env=None, d=None):
except UnsupportedTerminal:
continue
else:
- raise NoSupportedTerminals()
+ raise NoSupportedTerminals(get_cmd_list())
def spawn(name, sh_cmd, title=None, env=None, d=None):
"""Spawn the specified terminal, by name"""
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v2] cpufreq: conservative: Decrease frequency faster when the update deferred
From: Stratos Karafotis @ 2016-11-14 21:46 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Viresh Kumar, linux-pm@vger.kernel.org, LKML
In-Reply-To: <CAJZ5v0hREE4Q72XXqJS5ub+GEqw8=R111Svd2Z+A9pKuE3btcQ@mail.gmail.com>
On 14/11/2016 10:44 μμ, Rafael J. Wysocki wrote:
> On Sat, Nov 12, 2016 at 10:04 PM, Stratos Karafotis
> <stratosk@semaphore.gr> wrote:
>> Conservative governor changes the CPU frequency in steps.
>> That means that if a CPU runs at max frequency, it will need several
>> sampling periods to return to min frequency when the workload
>> is finished.
>>
>> If the update function that calculates the load and target frequency
>> is deferred, the governor might need even more time to decrease the
>> frequency.
>>
>> This may have impact to power consumption and after all conservative
>> should decrease the frequency if there is no workload at every sampling
>> rate.
>>
>> To resolve the above issue calculate the number of sampling periods
>> that the update is deferred. Considering that for each sampling period
>> conservative should drop the frequency by a freq_step because the
>> CPU was idle apply the proper subtraction to requested frequency.
>>
>> Below, the kernel trace with and without this patch. First an
>> intensive workload is applied on a specific CPU. Then the workload
>> is removed and the CPU goes to idle.
>>
>> WITHOUT
>>
>> <idle>-0 [007] dN.. 620.329153: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 620.350857: cpu_frequency: state=1700000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.370856: cpu_frequency: state=1900000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.390854: cpu_frequency: state=2100000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.411853: cpu_frequency: state=2200000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.432854: cpu_frequency: state=2400000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.453854: cpu_frequency: state=2600000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.494856: cpu_frequency: state=2900000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.515856: cpu_frequency: state=3100000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.536858: cpu_frequency: state=3300000 cpu_id=7
>> kworker/7:2-556 [007] .... 620.557857: cpu_frequency: state=3401000 cpu_id=7
>> <idle>-0 [007] d... 669.591363: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 669.591939: cpu_idle: state=4294967295 cpu_id=7
>> <idle>-0 [007] d... 669.591980: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] dN.. 669.591989: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 670.201224: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 670.221975: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 670.222016: cpu_frequency: state=3300000 cpu_id=7
>> <idle>-0 [007] d... 670.222026: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 670.234964: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 670.801251: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 671.236046: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 671.236073: cpu_frequency: state=3100000 cpu_id=7
>> <idle>-0 [007] d... 671.236112: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 671.393437: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 671.401277: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 671.404083: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 671.404111: cpu_frequency: state=2900000 cpu_id=7
>> <idle>-0 [007] d... 671.404125: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 671.404974: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 671.501180: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 671.995414: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 671.995459: cpu_frequency: state=2800000 cpu_id=7
>> <idle>-0 [007] d... 671.995469: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 671.996287: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 672.001305: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.078374: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 672.078410: cpu_frequency: state=2600000 cpu_id=7
>> <idle>-0 [007] d... 672.078419: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.158020: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 672.158040: cpu_frequency: state=2400000 cpu_id=7
>> <idle>-0 [007] d... 672.158044: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.160038: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 672.234557: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.237121: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 672.237174: cpu_frequency: state=2100000 cpu_id=7
>> <idle>-0 [007] d... 672.237186: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.237778: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 672.267902: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.269860: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 672.269906: cpu_frequency: state=1900000 cpu_id=7
>> <idle>-0 [007] d... 672.269914: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.271902: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 672.751342: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 672.823056: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-556 [007] .... 672.823095: cpu_frequency: state=1600000 cpu_id=7
>>
>> WITH
>>
>> <idle>-0 [007] dN.. 4380.928009: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-399 [007] .... 4380.949767: cpu_frequency: state=2000000 cpu_id=7
>> kworker/7:2-399 [007] .... 4380.969765: cpu_frequency: state=2200000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.009766: cpu_frequency: state=2500000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.029767: cpu_frequency: state=2600000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.049769: cpu_frequency: state=2800000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.069769: cpu_frequency: state=3000000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.089771: cpu_frequency: state=3100000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.109772: cpu_frequency: state=3400000 cpu_id=7
>> kworker/7:2-399 [007] .... 4381.129773: cpu_frequency: state=3401000 cpu_id=7
>> <idle>-0 [007] d... 4428.226159: cpu_idle: state=1 cpu_id=7
>> <idle>-0 [007] d... 4428.226176: cpu_idle: state=4294967295 cpu_id=7
>> <idle>-0 [007] d... 4428.226181: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 4428.227177: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 4428.551640: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 4428.649239: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-399 [007] .... 4428.649268: cpu_frequency: state=2800000 cpu_id=7
>> <idle>-0 [007] d... 4428.649278: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 4428.689856: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 4428.799542: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 4428.801683: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-399 [007] .... 4428.801748: cpu_frequency: state=1700000 cpu_id=7
>> <idle>-0 [007] d... 4428.801761: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 4428.806545: cpu_idle: state=4294967295 cpu_id=7
>> ...
>> <idle>-0 [007] d... 4429.051880: cpu_idle: state=4 cpu_id=7
>> <idle>-0 [007] d... 4429.086240: cpu_idle: state=4294967295 cpu_id=7
>> kworker/7:2-399 [007] .... 4429.086293: cpu_frequency: state=1600000 cpu_id=7
>>
>> Without the patch the CPU dropped to min frequency after 3.2s
>> With the patch applied the CPU dropped to min frequency after 0.86s
>>
>> Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
>> ---
>> v1 -> v2
>> - Use correct terminology in change log
>> - Change the member variable name from 'deferred_periods' to 'idle_periods'
>> - Fix format issue
>>
>> drivers/cpufreq/cpufreq_conservative.c | 14 +++++++++++++-
>> drivers/cpufreq/cpufreq_governor.c | 18 +++++++++++++-----
>> drivers/cpufreq/cpufreq_governor.h | 1 +
>> 3 files changed, 27 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
>> index fa5ece3..d787772 100644
>> --- a/drivers/cpufreq/cpufreq_conservative.c
>> +++ b/drivers/cpufreq/cpufreq_conservative.c
>> @@ -73,7 +73,19 @@ static unsigned int cs_dbs_update(struct cpufreq_policy *policy)
>> */
>> if (cs_tuners->freq_step == 0)
>> goto out;
>> -
>> + /*
>> + * Decrease requested_freq for each idle period that we didn't
>> + * update the frequency
>> + */
>> + if (policy_dbs->idle_periods < UINT_MAX) {
>> + unsigned int freq_target = policy_dbs->idle_periods *
>> + get_freq_target(cs_tuners, policy);
>> + if (requested_freq > freq_target)
>> + requested_freq -= freq_target;
>> + else
>> + requested_freq = policy->min;
>> + policy_dbs->idle_periods = UINT_MAX;
>> + }
>> /*
>> * If requested_freq is out of range, it is likely that the limits
>> * changed in the meantime, so fall back to current frequency in that
>> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
>> index 3729474..1bc7137 100644
>> --- a/drivers/cpufreq/cpufreq_governor.c
>> +++ b/drivers/cpufreq/cpufreq_governor.c
>> @@ -117,7 +117,7 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>> struct policy_dbs_info *policy_dbs = policy->governor_data;
>> struct dbs_data *dbs_data = policy_dbs->dbs_data;
>> unsigned int ignore_nice = dbs_data->ignore_nice_load;
>> - unsigned int max_load = 0;
>> + unsigned int max_load = 0, idle_periods = UINT_MAX;
>> unsigned int sampling_rate, io_busy, j;
>>
>> /*
>> @@ -163,8 +163,12 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>> * calls, so the previous load value can be used then.
>> */
>> load = j_cdbs->prev_load;
>> - } else if (unlikely(time_elapsed > 2 * sampling_rate &&
>> - j_cdbs->prev_load)) {
>> + } else if (unlikely(time_elapsed > 2 * sampling_rate)) {
>> + unsigned int periods = time_elapsed / sampling_rate;
>> +
>> + if (periods < idle_periods)
>> + idle_periods = periods;
>> +
>> /*
>> * If the CPU had gone completely idle and a task has
>> * just woken up on this CPU now, it would be unfair to
>> @@ -189,8 +193,10 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>> * 'time_elapsed' (as compared to the sampling rate)
>> * indicates this scenario.
>> */
>> - load = j_cdbs->prev_load;
>> - j_cdbs->prev_load = 0;
>> + if (j_cdbs->prev_load) {
>> + load = j_cdbs->prev_load;
>> + j_cdbs->prev_load = 0;
>> + }
>> } else {
>> if (time_elapsed >= idle_time) {
>> load = 100 * (time_elapsed - idle_time) / time_elapsed;
>> @@ -218,6 +224,8 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>> if (load > max_load)
>> max_load = load;
>> }
>> + policy_dbs->idle_periods = idle_periods;
>> +
>> return max_load;
>> }
>> EXPORT_SYMBOL_GPL(dbs_update);
>
> I have a murky suspicion that the changes in dbs_update() are going to
> break something. I need to recall what it was, though.
The only change in dbs_update() is the calculation of 'idle_periods'.
If I don't miss something I left current functionality untouched.
But you know better. :)
Please let me know if you want me to proceed with the changes that
Viresh suggested.
Thank you both for your time.
Regards,
Stratos
^ permalink raw reply
* Re: [dm-crypt] License Clarification
From: Nathaniel McCallum @ 2016-11-14 21:47 UTC (permalink / raw)
To: Milan Broz; +Cc: dm-crypt, Sorce, Simo
In-Reply-To: <5f467a08-bb2f-7919-cd91-45933ec47f00@gmail.com>
Thanks for the response. My particular concern is the ability to link
to both libcryptsetup and openssl higher up in the stack.
On Mon, Nov 14, 2016 at 3:22 PM, Milan Broz <gmazyland@gmail.com> wrote:
> The original intention is documented here
> http://www.saout.de/pipermail/dm-crypt/2012-December/002992.html
>
> Anyway, I have contacted lawyers to check it and for possible
> guidance if a fix is needed.
>
> Thanks,
> Milan
>
> On 11/10/2016 08:41 PM, Nathaniel McCallum wrote:
>> In reviewing the license choices of a set of my projects, I have
>> noticed an inconsistency in licensing and I would like to receive some
>> clarification.
>>
>> There is a commit that changes some of the code to LGPLv2.1+:
>> https://gitlab.com/cryptsetup/cryptsetup/commit/7eccb7ff5031a4f42f1ae8f7ffaefe80ba0d53dd
>>
>> However, the main header still reads GPLv2+:
>> https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/libcryptsetup.h
>>
>> Further, the API examples have LGPLv2.1+:
>> https://gitlab.com/cryptsetup/cryptsetup/wikis/API/index.html
>>
>> Again, the openssl crypto backend are licensed as LGPLv2.1+ w/ openssl
>> exception. However, this exception doesn't seem to apply to the whole
>> library:
>> https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/crypto_backend/crypto_openssl.c
>>
>> In short, it is very unclear to me how this licensing is supposed to work.
>>
>> The best I can ascertain is this:
>>
>> crypto-backend (LGPLv2+) ==> libcryptsetup (GPLv2+) ==> API examples (LGPLv2+)
>>
>> It would, thus, seem to me that the API examples are incompatibly
>> licensed and cannot actually link against libcryptsetup.
>>
>> Further, it seems to me that the crypto-backend can link against
>> openssl, but not libcryptsetup itself. This further implies that
>> consumers of libcryptsetup cannot link against openssl.
>>
>> Have I understood this correctly?
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
^ permalink raw reply
* perf: fuzzer KASAN slab-out-of-bounds in snb_uncore_imc_event_del
From: Vince Weaver @ 2016-11-14 21:49 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo, davej,
dvyukov, Stephane Eranian
After turning modversions off I finally managed to get a 4.9-rc kernel to
boot.
Anyway as per the suggestion at Linux Plumbers I enabled KASAN and on my
haswell machine it falls over in a few minutes of running the perf_fuzzer.
[ 205.740194] ==================================================================
[ 205.748005] BUG: KASAN: slab-out-of-bounds in snb_uncore_imc_event_del+0x6c/0xa0 at addr ffff8800caa43768
[ 205.758324] Read of size 8 by task perf_fuzzer/6618
[ 205.763589] CPU: 0 PID: 6618 Comm: perf_fuzzer Not tainted 4.9.0-rc5 #4
[ 205.770721] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS 01/26/2014
[ 205.778689] ffff8800c3c479b8 ffffffff816bb796 ffff88011ec00600 ffff8800caa43580
[ 205.786759] ffff8800c3c479e0 ffffffff812fb961 ffff8800c3c47a78 ffff8800caa43580
[ 205.794850] ffff8800caa43580 ffff8800c3c47a68 ffffffff812fbbd8 ffff8800c3c47a28
[ 205.802911] Call Trace:
[ 205.805559] [<ffffffff816bb796>] dump_stack+0x63/0x8d
[ 205.811135] [<ffffffff812fb961>] kasan_object_err+0x21/0x70
[ 205.817267] [<ffffffff812fbbd8>] kasan_report_error+0x1d8/0x4c0
[ 205.823752] [<ffffffff81133275>] ? __lock_is_held+0x75/0xc0
[ 205.829868] [<ffffffff81025b12>] ? snb_uncore_imc_read_counter+0x42/0x50
[ 205.837198] [<ffffffff810222e2>] ? uncore_perf_event_update+0xe2/0x160
[ 205.844337] [<ffffffff812fc319>] kasan_report+0x39/0x40
[ 205.850085] [<ffffffff81025e3c>] ? snb_uncore_imc_event_del+0x6c/0xa0
[ 205.857114] [<ffffffff812fa8fe>] __asan_load8+0x5e/0x70
[ 205.862874] [<ffffffff81025e3c>] snb_uncore_imc_event_del+0x6c/0xa0
[ 205.869727] [<ffffffff81241bd2>] event_sched_out.isra.89+0x192/0x690
[ 205.876664] [<ffffffff81242167>] group_sched_out+0x97/0x170
[ 205.882760] [<ffffffff81242810>] __perf_event_disable+0x140/0x1b0
[ 205.889395] [<ffffffff812384e7>] event_function+0x117/0x1f0
[ 205.895503] [<ffffffff812426d0>] ? task_ctx_sched_out+0x60/0x60
[ 205.901959] [<ffffffff812383d0>] ? update_group_times+0x50/0x50
[ 205.908425] [<ffffffff8123b020>] ? perf_cgroup_attach+0xb0/0xb0
[ 205.914937] [<ffffffff8123b096>] remote_function+0x76/0xa0
[ 205.920955] [<ffffffff8118da7c>] generic_exec_single+0xfc/0x170
[ 205.927434] [<ffffffff8123b020>] ? perf_cgroup_attach+0xb0/0xb0
[ 205.933883] [<ffffffff8118dc30>] smp_call_function_single+0x140/0x1b0
[ 205.940967] [<ffffffff8118daf0>] ? generic_exec_single+0x170/0x170
[ 205.947776] [<ffffffff81238e48>] event_function_call+0x268/0x270
[ 205.954336] [<ffffffff812426d0>] ? task_ctx_sched_out+0x60/0x60
[ 205.960806] [<ffffffff81238be0>] ? task_function_call+0xc0/0xc0
[ 205.967276] [<ffffffff812426d0>] ? task_ctx_sched_out+0x60/0x60
[ 205.973740] [<ffffffff81238e79>] ? _perf_event_disable+0x29/0x70
[ 205.980300] [<ffffffff812383d0>] ? update_group_times+0x50/0x50
[ 205.986750] [<ffffffff81238e97>] ? _perf_event_disable+0x47/0x70
[ 205.993338] [<ffffffff8113a4d7>] ? do_raw_spin_unlock+0x97/0x130
[ 205.999906] [<ffffffff81238e50>] ? event_function_call+0x270/0x270
[ 206.006674] [<ffffffff81238ea8>] _perf_event_disable+0x58/0x70
[ 206.013069] [<ffffffff812386a3>] perf_event_for_each_child+0x53/0xd0
[ 206.019990] [<ffffffff81247a51>] perf_event_task_disable+0x61/0xc0
[ 206.026759] [<ffffffff810daee2>] SyS_prctl+0x3f2/0x690
[ 206.032409] [<ffffffff810daaf0>] ? SyS_umask+0x40/0x40
[ 206.038059] [<ffffffff81b8dabb>] entry_SYSCALL_64_fastpath+0x1e/0xb2
[ 206.045007] Object at ffff8800caa43580, in cache kmalloc-512 size: 512
[ 206.052015] Allocated:
[ 206.054565] PID = 1
[ 206.056842] [ 206.058367] [<ffffffff8105fcdb>] save_stack_trace+0x1b/0x20
[ 206.064410] [ 206.065933] [<ffffffff812facc6>] save_stack+0x46/0xd0
[ 206.071416] [ 206.072953] [<ffffffff812faf3d>] kasan_kmalloc+0xad/0xe0
[ 206.078683] [ 206.080214] [<ffffffff812f7e3a>] __kmalloc_node+0x4a/0x60
[ 206.086061] [ 206.087590] [<ffffffff81020799>] uncore_alloc_box+0x39/0x150
[ 206.093685] [ 206.095208] [<ffffffff81020b8f>] uncore_pci_probe+0xff/0x4f0
[ 206.101357] [ 206.102879] [<ffffffff8172bc7a>] local_pci_probe+0x7a/0xd0
[ 206.108816] [ 206.110347] [<ffffffff8172df6e>] pci_device_probe+0x19e/0x1f0
[ 206.116553] [ 206.118073] [<ffffffff818a9a1d>] driver_probe_device+0x25d/0x400
[ 206.124566] [ 206.126087] [<ffffffff818a9c9c>] __driver_attach+0xdc/0xe0
[ 206.132021] [ 206.133534] [<ffffffff818a653b>] bus_for_each_dev+0xeb/0x150
[ 206.139654] [ 206.141184] [<ffffffff818a8f2b>] driver_attach+0x2b/0x30
[ 206.146948] [ 206.148493] [<ffffffff818a8900>] bus_add_driver+0x2b0/0x330
[ 206.154519] [ 206.156042] [<ffffffff818aa9f3>] driver_register+0xd3/0x190
[ 206.164160] [ 206.165688] [<ffffffff8172b2b4>] __pci_register_driver+0xb4/0xc0
[ 206.174265] [ 206.175783] [<ffffffff8261553b>] intel_uncore_init+0x2f3/0x388
[ 206.184162] [ 206.185672] [<ffffffff81002258>] do_one_initcall+0xa8/0x210
[ 206.193721] [ 206.195261] [<ffffffff8260e4c2>] kernel_init_freeable+0x27c/0x312
[ 206.203821] [ 206.205349] [<ffffffff81b80b13>] kernel_init+0x13/0x120
[ 206.212889] [ 206.214439] [<ffffffff81b8dd35>] ret_from_fork+0x25/0x30
[ 206.222067] Freed:
[ 206.226172] PID = 0
[ 206.230341] (stack is not available)
[ 206.236044] Memory state around the buggy address:
[ 206.243157] ffff8800caa43600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 206.252788] ffff8800caa43680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 206.262437] >ffff8800caa43700: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
[ 206.272071] ^
[ 206.281005] ffff8800caa43780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 206.290640] ffff8800caa43800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 206.300302]
==================================================================
^ permalink raw reply
* [PATCH v2 1/2] drm/dp/i915: Fix DP link rate math
From: Dhinakaran Pandiyan @ 2016-11-14 21:50 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula, Dhinakaran Pandiyan
In-Reply-To: <1479159735-29364-1-git-send-email-dhinakaran.pandiyan@intel.com>
We store DP link rates as link clock frequencies in kHz, just like all
other clock values. But, DP link rates in the DP Spec. are expressed in
Gbps/lane, which seems to have led to some confusion.
E.g., for HBR2
Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 2160000 kBps
where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion
Using link clock frequency, like we do
Max. data rate = 540000 kHz * 4 lanes = 2160000 kSymbols/s
Because, each symbol has 8 bit of data, this is 2160000 kBps
and there is no need to account for channel encoding here.
But, currently we do 540000 kHz * 4 lanes * (8/10) = 1728000 kBps
Similarly, while computing the required link bandwidth for a mode,
there is a mysterious 1/10 term.
This should simply be pixel_clock kHz * (bpp/8) to give the final result in
kBps
v2: Changed to DIV_ROUND_UP() and comment changes (Ville)
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
---
Fixed a typo that snuck in.
drivers/gpu/drm/i915/intel_dp.c | 35 +++++++++++++++--------------------
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8f313c1..bdef314 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
return min(source_max, sink_max);
}
-/*
- * The units on the numbers in the next two are... bizarre. Examples will
- * make it clearer; this one parallels an example in the eDP spec.
- *
- * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
- *
- * 270000 * 1 * 8 / 10 == 216000
- *
- * The actual data capacity of that configuration is 2.16Gbit/s, so the
- * units are decakilobits. ->clock in a drm_display_mode is in kilohertz -
- * or equivalently, kilopixels per second - so for 1680x1050R it'd be
- * 119000. At 18bpp that's 2142000 kilobits per second.
- *
- * Thus the strange-looking division by 10 in intel_dp_link_required, to
- * get the result in decakilobits instead of kilobits.
- */
-
static int
intel_dp_link_required(int pixel_clock, int bpp)
{
- return (pixel_clock * bpp + 9) / 10;
+ /* pixel_clock is in kHz, divide bpp by 8 for bit to Byte conversion */
+ return DIV_ROUND_UP(pixel_clock * bpp, 8);
}
static int
intel_dp_max_data_rate(int max_link_clock, int max_lanes)
{
- return (max_link_clock * max_lanes * 8) / 10;
+ /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
+ * link rate that is generally expressed in Gbps. Since, 8 bits of data
+ * is transmitted every LS_Clk per lane, there is no need to account for
+ * the channel encoding that is done in the PHY layer here.
+ */
+
+ return max_link_clock * max_lanes;
}
static int
@@ -3573,7 +3563,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (val == 0)
break;
- /* Value read is in kHz while drm clock is saved in deca-kHz */
+ /* Value read multiplied by 200kHz gives the per-lane
+ * link rate in kHz. The source rates are, however,
+ * stored in terms of LS_Clk kHz. The full conversion
+ * back to symbols is
+ * (val * 200kHz)*(8/10 ch. encoding)*(1/8 bit to Byte)
+ */
intel_dp->sink_rates[i] = (val * 200) / 10;
}
intel_dp->num_sink_rates = i;
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.