Re: [PATCH v2] soc: mediatek: add scpsys support active_wakeup
On Wed, 2015-08-26 at 05:11 +0800, Daniel Kurtz wrote:
> Hi Eddie,
>
> On Tue, Aug 25, 2015 at 2:00 PM, Eddie Huang wrote:
> > Register gpd_dev_ops.active_wakeup function to support keep power
> > during suspend state. And add flag to each power domain to
> > decide whether keep power during suspend or not.
> >
> > Signed-off-by: Chunfeng Yun
> > Signed-off-by: Eddie Huang
> > Acked-by: Sascha Hauer
> >
> > ---
> > Change in v2:
> > Drop .active_wakeup = false lines in scp_domain_data[] array
> >
> > ---
> > drivers/soc/mediatek/mtk-scpsys.c | 19 +++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c
> > b/drivers/soc/mediatek/mtk-scpsys.c
> > index 43a79ed..df2f288 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -67,6 +67,7 @@ struct scp_domain_data {
> > u32 sram_pdn_ack_bits;
> > u32 bus_prot_mask;
> > enum clk_id clk_id;
> > + bool active_wakeup;
> > };
> >
> > static const struct scp_domain_data scp_domain_data[] __initconst = {
> > @@ -127,6 +128,7 @@ static const struct scp_domain_data scp_domain_data[]
> > __initconst = {
> > .sram_pdn_bits = GENMASK(11, 8),
> > .sram_pdn_ack_bits = GENMASK(15, 12),
> > .clk_id = MT8173_CLK_NONE,
> > + .active_wakeup = true,
> > },
> > [MT8173_POWER_DOMAIN_MFG_ASYNC] = {
> > .name = "mfg_async",
> > @@ -171,6 +173,7 @@ struct scp_domain {
> > u32 sram_pdn_bits;
> > u32 sram_pdn_ack_bits;
> > u32 bus_prot_mask;
> > + bool active_wakeup;
> > };
> >
> > struct scp {
> > @@ -370,6 +373,20 @@ out:
> > return ret;
> > }
> >
> > +static bool scpsys_active_wakeup(struct device *dev)
> > +{
> > + struct generic_pm_domain *genpd;
> > + struct scp_domain *scpd;
> > +
> > + if (IS_ERR_OR_NULL(dev->pm_domain))
> > + return false;
>
> Is it really possible to get here w/ pm_domain as an ERR or NULL?
> If the power core can ensure this cannot happen, then this function
> could be a bit simpler.
>
> Other than that, this patch is:
> Reviewed-by: Daniel Kurtz
>
> -Dan
>
After checking drivers/base/power/domain.c, I believe check
dev->pm_domain here is redundant, I will remove it.
Eddie
Thanks
--
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 RFC RFT 0/3] clk: detect per-user enable imbalances and implement hand-off
On Tue, 25 Aug 2015, Michael Turquette wrote: > Quoting Maxime Ripard (2015-08-20 08:15:10) > > On Tue, Aug 18, 2015 at 09:43:56AM -0700, Michael Turquette wrote: > > > Quoting Maxime Ripard (2015-08-18 08:45:52) > > > > Hi Mike, > > > > > > > > On Fri, Aug 07, 2015 at 12:09:27PM -0700, Michael Turquette wrote: > > > > > All of the other kitchen sink stuff (DT binding, passing the flag back > > > > > to the framework when the clock consumer driver calls clk_put) was > > > > > left > > > > > out because I do not see a real use case for it. If one can > > > > > demonstrate > > > > > a real use case (and not a hypothetical one) then this patch series > > > > > can > > > > > be expanded further. > > > > > > > > I think there is a very trivial use case for passing back the > > > > reference to the framework, if during the probed, we have something > > > > like: > > > > > > > > clk = clk_get() > > > > clk_prepare_enable(clk) > > > > foo_framework_register() > > > > > > > > if foo_framework_register fails, the sensible thing to do would be to > > > > call clk_disable_unprepare. If the clock was a critical clock, you > > > > just gated it. > > > > > > Hmm, a good point. Creating the "pass the reference back" call is not > > > hard technically. But how to keep from abusing it? E.g. I do not want > > > that call to become an alternative to correct use of clk_enable. > > > > > > Maybe I'll need a Coccinelle script or just some regular sed to > > > occasionally search for new users of this api and audit them? > > > > > > I was hoping to not add any new consumer api at all :-/ > > > > I don't think there's any abuse that can be done with the current API, > > nor do I think you need to have new functions either. > > > > If the clock is critical, when the customer calls > > clk_unprepare_disable on it, simply take back the reference you gave > > in the framework, and you're done. Or am I missing something? > > Maybe I am the one missing something? My goal was to allow the consumer > driver to gate the critical clock. So we need clk_disable_unused to > actually disable the clock for that to work. > > I think you are suggesting that clk_disable_unused should *not* disable > the clock if it is critical. Can you confirm that? My take is that a critical clock should only be disabled when a knowledgeable driver wants to gate it for a specific purpose [probably using clk_disable()]. Once the aforementioned driver no longer has a use for the clock [whether that happens with clk_unprepare_disable() or clk_put() ...] the clock should be ungated and be provided with critical status once more. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver
On Wed, Aug 26, 2015 at 10:16 AM, Viresh Kumar wrote: > On 26-08-15, 09:25, Pi-Cheng Chen wrote: >> The [3/3] is based on Mediatek SoC maintainer tree[1] and the patch which >> introduce a new clock type[2] consumed by MT8173 cpufreq driver. So it will >> cause some conflicts if it goes through your tree. I am not sure how this >> should be handled, but should it be merged through Mediatek SoC maintainer >> tree? > > Just get that applied to MTK tree, it doesn't have any dependency on > rest of the patches for build/boot. The only thing is that cpufreq > wouldn't work and it will work as soon as Rafael's and MTK's trees are > merged by Linus. Thanks for your explanation. @Rafael, Would you please apply [1,2] to your tree? @Matthias, Would you please apply [3/3] of this series? Thanks. Best Regards, Pi-Cheng > > -- > 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 1/1] memhp: Add hot-added memory ranges to memblock before allocate node_data for a node.
On 08/25/2015 09:09 AM, Xishi Qiu wrote: On 2015/8/24 17:22, Xishi Qiu wrote: On 2015/8/24 1:06, Tang Chen wrote: The commit below adds hot-added memory range to memblock, after creating pgdat for new node. commit f9126ab9241f66562debf69c2c9d8fee32ddcc53 Author: Xishi Qiu Date: Fri Aug 14 15:35:16 2015 -0700 memory-hotplug: fix wrong edge when hot add a new node But there is a problem: add_memory() |--> hotadd_new_pgdat() |--> free_area_init_node() |--> get_pfn_range_for_nid() |--> find start_pfn and end_pfn in memblock |--> .. |--> memblock_add_node(start, size, nid)Here, just too late. get_pfn_range_for_nid() will find that start_pfn and end_pfn are both 0. As a result, when adding memory, dmesg will give the following wrong message. Hi Tang, Another question, if we add cpu first, there will be print error too. cpu_up() try_online_node() hotadd_new_pgdat() So how about just skip the print if the size is empty or just print "node xx is empty now, will update when online memory"? As Liu Jiang said, memory-less node is not supported on x86 now. And he is working on it. Please refer to https://lkml.org/lkml/2015/8/16/130. About your question, now, node could only be onlined when it has some memory. So the printed message is also about memory, and sis put in hotadd_new_pgdat() . I think the author of the code didn't think about online a node when a CPU is up. But now, memory-less will be supported. So, I think, as you said, the message should be modified. But how it will go, I think we should refer to Liu Jiang's patch, and make a decision. Thanks. Thanks, Xishi Qiu [ 2007.577000] Initmem setup node 5 [mem 0x-0x] [ 2007.584000] On node 5 totalpages: 0 [ 2007.585000] Built 5 zonelists in Node order, mobility grouping on. Total pages: 32588823 [ 2007.594000] Policy zone: Normal [ 2007.598000] init_memory_mapping: [mem 0x600-0x607] -- 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/ . -- 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 10/10] scsi: ufs-exynos: add UFS host support for Exynos SoCs
On Fri, Aug 21, 2015 at 2:58 PM, Alim Akhtar wrote:
> From: Seungwon Jeon
>
> This patch introduces Exynos UFS host controller driver,
> which mainly handles vendor-specific operations including
> link startup, power mode change and hibernation/unhibernation.
>
> Signed-off-by: Seungwon Jeon
> Signed-off-by: Alim Akhtar
> ---
> .../devicetree/bindings/ufs/ufs-exynos.txt | 92 ++
> drivers/scsi/ufs/Kconfig | 12 +
> drivers/scsi/ufs/Makefile |1 +
> drivers/scsi/ufs/ufs-exynos-hw.c | 147 +++
> drivers/scsi/ufs/ufs-exynos-hw.h | 43 +
> drivers/scsi/ufs/ufs-exynos.c | 1175
>
> drivers/scsi/ufs/ufs-exynos.h | 463
> drivers/scsi/ufs/ufshci.h | 26 +-
> drivers/scsi/ufs/unipro.h | 47 +
> 9 files changed, 2005 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt
> create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
> create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
> create mode 100644 drivers/scsi/ufs/ufs-exynos.c
> create mode 100644 drivers/scsi/ufs/ufs-exynos.h
>
> diff --git a/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
> b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
> new file mode 100644
> index 000..1a6184d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
> @@ -0,0 +1,92 @@
> +* Exynos Universal Flash Storage (UFS) Host Controller
> +
> +UFSHC nodes are defined to describe on-chip UFS host controllers.
> +Each UFS controller instance should have its own node.
> +
> +Required properties:
> +- compatible: compatible list, contains "samsung,exynos7-ufs"
> +- interrupts:
> +- reg :
> +
> +Optional properties:
> +- vdd-hba-supply: phandle to UFS host controller supply regulator
> node
> +- vcc-supply: phandle to VCC supply regulator node
> +- vccq-supply : phandle to VCCQ supply regulator node
> +- vccq2-supply : phandle to VCCQ2 supply regulator node
> +- vcc-supply-1p8: For embedded UFS devices, valid VCC range is
> 1.7-1.95V
> + or 2.7-3.6V. This boolean property when set,
> specifies
> + to use low voltage range of 1.7-1.95V. Note for
> external
> + UFS cards this property is invalid and valid VCC
> range is
> + always 2.7-3.6V.
> +- vcc-max-microamp : specifies max. load that can be drawn from vcc
> supply
> +- vccq-max-microamp : specifies max. load that can be drawn from vccq
> supply
> +- vccq2-max-microamp: specifies max. load that can be drawn from vccq2
> supply
> +- -fixed-regulator : boolean property specifying that -supply is
> a fixed regulator
> +
> +- clocks: List of phandle and clock specifier pairs
> +- clock-names : List of clock input name strings sorted in the same
> + order as the clocks property.
> +- freq-table-hz: Array of operating frequencies
> stored in the same
> + order as the clocks property. If this property is
> not
> + defined or a value in the array is "0" then it is
> assumed
> + that the frequency is set by the parent clock or a
> + fixed rate clock source.
> +- pclk-freq-avail-range : specifies available frequency range(min/max) for
> APB clock
> +- ufs,pwr-attr-mode : specifies mode value for power mode change
> +- ufs,pwr-attr-lane : specifies lane count value for power mode change
> +- ufs,pwr-attr-gear : specifies gear count value for power mode change
> +- ufs,pwr-attr-hs-series : specifies HS rate series for power mode change
> +- ufs,pwr-local-l2-timer : specifies array of local UNIPRO L2 timer values
> + AFC0ReqTimeOutVal>
> +- ufs,pwr-remote-l2-timer : specifies array of remote UNIPR L2 timer values
s/UNIPR/UNIPRO
> + AFC0ReqTimeOutVal>
> +- ufs-rx-adv-fine-gran-sup_en : specifies support of fine granularity of MPHY
I suppose this field is bool type. This can be mentioned here.
> +- ufs-rx-adv-fine-gran-step : specifies granularity steps of MPHY
> +- ufs-rx-adv-min-activate-time-cap : specifies rx advanced minimum activate
> time of MPHY
> +- ufs-pa-granularity : specifies Granularity for PA_TActivate and
> PA_Hibern8Time
> +- ufs-pa-tacctivate : specifies time wake-up remote M-RX
> +- ufs-pa-hibern8time : specifies minimum time to wait in HIBERN8 state
> +
> +Note: If above properties are not defined it can be assumed that the supply
> +regulators or clocks are always on.
> +
> +Example:
> + ufshc@0x1557 {
> + compatible = "samsung,exynos7-ufs";
> + reg = <0xfc59800
[LINUX RFC v2 4/4] spi: zynqmp: gqspi: add support for dual parallel mode configuration
This patch adds support of dual parallel mode configuration
for Zynq Ultrascale+ MPSoC GQSPI controller driver.
Signed-off-by: Ranjit Waghmode
---
V2 Changes:
- No change in this patch
---
drivers/spi/spi-zynqmp-gqspi.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index f23f36e..7a72781 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -153,6 +153,7 @@ enum mode_type {GQSPI_MODE_IO, GQSPI_MODE_DMA};
* @dma_rx_bytes: Remaining bytes to receive by DMA mode
* @dma_addr: DMA address after mapping the kernel buffer
* @genfifoentry: Used for storing the genfifoentry instruction.
+ * @isinstr: To determine whether the transfer is instruction
* @mode: Defines the mode in which QSPI is operating
*/
struct zynqmp_qspi {
@@ -170,6 +171,7 @@ struct zynqmp_qspi {
u32 dma_rx_bytes;
dma_addr_t dma_addr;
u32 genfifoentry;
+ bool isinstr;
enum mode_type mode;
};
@@ -405,9 +407,20 @@ static void zynqmp_qspi_chipselect(struct spi_device
*qspi, bool is_high)
genfifoentry |= GQSPI_GENFIFO_MODE_SPI;
genfifoentry |= xqspi->genfifobus;
+ if (qspi->master->flags & SPI_MASTER_BOTH_CS) {
+ zynqmp_gqspi_selectslave(xqspi,
+ GQSPI_SELECT_FLASH_CS_BOTH,
+ GQSPI_SELECT_FLASH_BUS_BOTH);
+ } else {
+ zynqmp_gqspi_selectslave(xqspi,
+ GQSPI_SELECT_FLASH_CS_LOWER,
+ GQSPI_SELECT_FLASH_BUS_LOWER);
+ }
+
if (!is_high) {
genfifoentry |= xqspi->genfifocs;
genfifoentry |= GQSPI_GENFIFO_CS_SETUP;
+ xqspi->isinstr = true;
} else {
genfifoentry |= GQSPI_GENFIFO_CS_HOLD;
}
@@ -664,6 +677,7 @@ static irqreturn_t zynqmp_qspi_irq(int irq, void *dev_id)
if ((xqspi->bytes_to_receive == 0) && (xqspi->bytes_to_transfer == 0)
&& ((status & GQSPI_IRQ_MASK) == GQSPI_IRQ_MASK)) {
zynqmp_gqspi_write(xqspi, GQSPI_IDR_OFST, GQSPI_ISR_IDR_MASK);
+ xqspi->isinstr = false;
spi_finalize_current_transfer(master);
ret = IRQ_HANDLED;
}
@@ -827,6 +841,9 @@ static int zynqmp_qspi_start_transfer(struct spi_master
*master,
genfifoentry |= xqspi->genfifocs;
genfifoentry |= xqspi->genfifobus;
+ if ((!xqspi->isinstr) && (master->flags & SPI_MASTER_DATA_STRIPE))
+ genfifoentry |= GQSPI_GENFIFO_STRIPE;
+
zynqmp_qspi_txrxsetup(xqspi, transfer, &genfifoentry);
if (xqspi->mode == GQSPI_MODE_DMA)
@@ -983,6 +1000,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
struct zynqmp_qspi *xqspi;
struct resource *res;
struct device *dev = &pdev->dev;
+ u32 num_cs;
master = spi_alloc_master(&pdev->dev, sizeof(*xqspi));
if (!master)
@@ -1043,7 +1061,11 @@ static int zynqmp_qspi_probe(struct platform_device
*pdev)
goto clk_dis_all;
}
- master->num_chipselect = GQSPI_DEFAULT_NUM_CS;
+ ret = of_property_read_u32(pdev->dev.of_node, "num-cs", &num_cs);
+ if (ret < 0)
+ master->num_chipselect = GQSPI_DEFAULT_NUM_CS;
+ else
+ master->num_chipselect = num_cs;
master->setup = zynqmp_qspi_setup;
master->set_cs = zynqmp_qspi_chipselect;
--
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/
Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status
On Tue 25-08-15 16:23:34, David Rientjes wrote: > On Mon, 24 Aug 2015, Michal Hocko wrote: > > > The current implementation makes me worry. Is the per hstate break down > > really needed? The implementation would be much more easier without it. > > > > Yes, it's needed. It provides a complete picture of what statically > reserved hugepages are in use and we're not going to change the > implementation when it is needed to differentiate between variable hugetlb > page sizes that risk breaking existing userspace parsers. I thought the purpose was to give the amount of hugetlb based resident memory. At least this is what Jörn was asking for AFAIU. /proc//status should be as lightweight as possible. The current implementation is quite heavy as already pointed out. So I am really curious whether this is _really_ needed. I haven't heard about a real usecase except for top displaying HRss which doesn't need the break down values. You have brought that up already http://marc.info/?l=linux-mm&m=143941143109335&w=2 and nobody actually asked for it. "I do not mind having it" is not an argument for inclusion especially when the implementation is more costly and touches hot paths. > > If you have 99% of hugetlb pages then your load is rather specific and I > > would argue that /proc//smaps (after patch 1) is a much better way to > > get what you want. > > Some distributions change the permissions of smaps, as already stated, for > pretty clear security reasons since it can be used to defeat existing > protection. There's no reason why hugetlb page usage should not be > exported in the same manner and location as memory usage. /proc//status provides only per-memory-type break down information (locked, data, stack, etc...). Different hugetlb sizes are still a hugetlb memory. So I am not sure I understand you argument here. -- Michal Hocko SUSE Labs -- 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/
[GIT PULL] drm/rockchip: fixes and new features
Hi Dave Here are some fixes and some new features for rockchip drm, tested on popmetal rk3288 board, can you land them? The following changes since commit db56176025cee5e242dfeed5f4e304d095d29fa3: Revert "drm/atomic: Call ww_acquire_done after check phase is complete" (2015-08-25 17:23:36 +1000) are available in the git repository at: https://github.com/markyzq/kernel-drm-rockchip.git drm-rockchip-2015-08-26 for you to fetch changes up to 4c156c21c7948a0be854cbe5914af3181303e529: drm/rockchip: vop: support plane scale (2015-08-26 14:16:26 +0800) Mark Yao (6): drm/rockchip: vop: Fix virtual stride calculation drm/rockchip: vop: Fix window dest start point drm/rockchip: vop: Add yuv plane support drm/rockchip: vop: Default enable win2/3 area0 bit drm/rockchip: vop: restore vop registers when resume drm/rockchip: vop: support plane scale drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 269 ++- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 88 + 2 files changed, 348 insertions(+), 9 deletions(-) -Mark -- 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: Next round: revised futex(2) man page for review
On Thu, Aug 20, 2015 at 01:17:03AM +0200, Thomas Gleixner wrote: ... > > >> .\" FIXME XXX In discussing errors for FUTEX_CMP_REQUEUE_PI, Darren Hart > > >> .\" made the observation that "EINVAL is returned if the non-pi > > >> .\" to pi or op pairing semantics are violated." > > >> .\" Probably there needs to be a general statement about this > > >> .\" requirement, probably located at about this point in the page. > > >> .\" Darren (or someone else), care to take a shot at this? > > > > > > Well, that's hard to describe because the kernel only has a limited > > > way of detecting such mismatches. It only can detect it when there are > > > non PI waiters on a futex and a PI function is called or vice versa. > > > > Hmmm. Okay, I filed your comments away for reference, but > > hopefully someone can help with some actual text. > > I let Darren come up with something sensible :) Heh, right, no pressure then... I responded to Michael on this recently, copied here for reference: FUTEX_WAIT_REQUEUE_PI can return -EINVAL if called with invalid parameters, such as uaddr==uaddr2, or (in the case of SHARED futexes), the associated keys match (meaning it's the same futex word - shared memory, inode, etc.). This can't happen if the stated policy of requeueing from non-pi to pi is followed as the same word cannot be both non-pi and pi at the same time, requiring them to be unique futex words. FUTEX_CMP_REQUEUE_PI will fail similarly if uaddr and uaddr2 are the same futex word. Also, if nr_wake != 1. But, to the point I was making above, FUTEX_CMP_REQUEUE_PI must requeue uaddr to the same uaddr2 specified in the previous FUTEX_WAIT_REQUEUE_PI call. FUTEX_WAIT_REQUEUE_PI sets up the operation, FUTEX_CMP_REQUEUE_PI completes it, and they must agree on uaddr and uaddr2. Michael, are you still looking for something more from me, or is this FIXME now complete? -- Darren Hart Intel Open Source Technology Center -- 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/
[LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller
This series adds dual parallel mode support for Zynq Ultrascale+ MPSoC GQSPI controller driver. What is dual parallel mode? --- ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities: 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines. 2) Chip selects and clock are shared to both the flash devices 3) This mode is targeted for faster read/write speed and also doubles the size 4) Commands/data can be transmitted/received from both the devices(mirror), or only upper or only lower flash memory devices. 5) Data arrangement: With stripe enabled, Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus. This series also updated MTD layer files for adding parallel mode support. 1) Added Support for two flashes 2) Support to enable/disable data stripe as and when required. 3) Added required parameters to spi_nor structure. Initialized all added parameters in spi_nor_scan() 4) Added support for dual parallel in spi_nor_read/write/erase functions by: a) Increasing page_size, sector_size, erase_size and toatal flash size as and when required. b) Dividing address by 2 c) Updating spi->master->flags for qspi driver to change CS 5) Updated read_sr() to get status of both flashes 6) Also updated read_fsr() to get status of both flashes These all are very high level changes and expected to make an idea clear. Comments and suggestions are always welcomed --- V2 Changes: a) Splitted patches based on logical changes b) Added error handling for newly added APIs in SPI core --- Ranjit Waghmode (4): spi: add support of two chip selects & data stripe mtd: add spi_device instance to spi_nor struct spi-nor: add dual parallel mode support spi: zynqmp: gqspi: add support for dual parallel mode configuration drivers/mtd/devices/m25p80.c | 1 + drivers/mtd/spi-nor/spi-nor.c | 91 +- drivers/spi/spi-zynqmp-gqspi.c | 24 ++- drivers/spi/spi.c | 8 include/linux/mtd/spi-nor.h| 3 ++ include/linux/spi/spi.h| 11 + 6 files changed, 118 insertions(+), 20 deletions(-) -- 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/
[LINUX RFC v2 3/4] spi-nor: add dual parallel mode support
This patch adds support for dual parallel configuration by:
- Adding required parameters like isparallel and shift to spi_nor structure.
- Initializing all added parameters in spi_nor_scan()
- Updating read_sr() and read_fsr() for getting status of both flashes
- Increasing page_size, sector_size, erase_size and toatal flash size
as and when required.
- Dividing address by 2
- Updating spi->master->flags for qspi driver to change CS
Signed-off-by: Ranjit Waghmode
---
V2 Changes:
Splitted to separate MTD layer changes from SPI core changes
---
drivers/mtd/spi-nor/spi-nor.c | 91 ++-
include/linux/mtd/spi-nor.h | 2 +
2 files changed, 74 insertions(+), 19 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index d78831b..6a2e80b 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
/* Define max times to check status register before we give up. */
#defineMAX_READY_WAIT_JIFFIES (40 * HZ) /* M25P16 specs 40s max chip
erase */
@@ -69,15 +70,24 @@ static const struct spi_device_id *spi_nor_match_id(const
char *name);
static int read_sr(struct spi_nor *nor)
{
int ret;
- u8 val;
+ u8 val[2];
- ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val, 1);
- if (ret < 0) {
- pr_err("error %d reading SR\n", (int) ret);
- return ret;
+ if (nor->isparallel) {
+ ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 2);
+ if (ret < 0) {
+ pr_err("error %d reading SR\n", (int) ret);
+ return ret;
+ }
+ val[0] |= val[1];
+ } else {
+ ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 1);
+ if (ret < 0) {
+ pr_err("error %d reading SR\n", (int) ret);
+ return ret;
+ }
}
- return val;
+ return val[0];
}
/*
@@ -87,16 +97,24 @@ static int read_sr(struct spi_nor *nor)
*/
static int read_fsr(struct spi_nor *nor)
{
- int ret;
- u8 val;
+ int ret, size;
+ u8 val[2];
+
+ size = 1;
+ val[1] = 0xff;
+
+ if (nor->isparallel)
+ size = 2;
- ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
+ ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], size);
if (ret < 0) {
pr_err("error %d reading FSR\n", ret);
return ret;
}
- return val;
+ val[0] &= val[1];
+
+ return val[0];
}
/*
@@ -317,6 +335,9 @@ static int spi_nor_erase(struct mtd_info *mtd, struct
erase_info *instr)
if (ret)
return ret;
+ if (nor->isparallel)
+ nor->spi->master->flags |= SPI_MASTER_DATA_STRIPE;
+
/* whole-chip erase? */
if (len == mtd->size) {
write_enable(nor);
@@ -340,6 +361,8 @@ static int spi_nor_erase(struct mtd_info *mtd, struct
erase_info *instr)
while (len) {
write_enable(nor);
+ addr = addr >> nor->shift;
+
if (nor->erase(nor, addr)) {
ret = -EIO;
goto erase_err;
@@ -360,19 +383,22 @@ static int spi_nor_erase(struct mtd_info *mtd, struct
erase_info *instr)
instr->state = MTD_ERASE_DONE;
mtd_erase_callback(instr);
-
+ if (nor->isparallel)
+ nor->spi->master->flags &= ~SPI_MASTER_DATA_STRIPE;
return ret;
erase_err:
spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_ERASE);
instr->state = MTD_ERASE_FAILED;
+ if (nor->isparallel)
+ nor->spi->master->flags &= ~SPI_MASTER_DATA_STRIPE;
return ret;
}
static int stm_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
{
struct mtd_info *mtd = nor->mtd;
- uint32_t offset = ofs;
+ uint32_t offset = ofs >> nor->shift;
uint8_t status_old, status_new;
int ret = 0;
@@ -406,7 +432,7 @@ static int stm_lock(struct spi_nor *nor, loff_t ofs,
uint64_t len)
static int stm_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
{
struct mtd_info *mtd = nor->mtd;
- uint32_t offset = ofs;
+ uint32_t offset = ofs >> nor->shift;
uint8_t status_old, status_new;
int ret = 0;
@@ -446,6 +472,8 @@ static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs,
uint64_t len)
if (ret)
return ret;
+ ofs = ofs >> nor->shift;
+
ret = nor->flash_lock(nor, ofs, len);
spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_UNLOCK);
@@ -461,6 +489,8 @@ static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs,
uint64_t len)
if (ret)
return ret;
+ ofs = ofs >> nor->shift;
+
ret = nor->flash_unlock(nor, ofs, len)
[LINUX RFC v2 2/4] mtd: add spi_device instance to spi_nor struct
This patch adds struct spi_device instacne to the spi_nor structure
Signed-off-by: Ranjit Waghmode
---
V2 Changes:
This is new patch, basically splitted on request of Mark Brown
---
drivers/mtd/devices/m25p80.c | 1 +
include/linux/mtd/spi-nor.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index d313f948b..174ed0f 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -207,6 +207,7 @@ static int m25p_probe(struct spi_device *spi)
spi_set_drvdata(spi, flash);
flash->mtd.priv = nor;
flash->spi = spi;
+ nor->spi = spi;
if (spi->mode & SPI_RX_QUAD)
mode = SPI_NOR_QUAD;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index e540952..1705dc3 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -163,6 +163,7 @@ struct spi_nor {
struct mtd_info *mtd;
struct mutexlock;
struct device *dev;
+ struct spi_device *spi;
u32 page_size;
u8 addr_width;
u8 erase_opcode;
--
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/
[LINUX RFC v2 1/4] spi: add support of two chip selects & data stripe
To support dual parallel mode operation of ZynqMP GQSPI controller
following API's are added inside the core:
- Added API to support two chip selects:
Dual parallel mode supports two SPI flash memories operating in
parallel i.e 8 I/O lines.
Chip selects and clock are shared to both the flash devices.
So newly added API will help in enabling both the chips.
- Added API to support data stripe feature:
with data stripe enabled,
even bytes i.e. 0, 2, 4,... are transmitted on lower data bus
odd bytes i.e. 1, 3, 5,.. are transmitted on upper data bus.
Signed-off-by: Ranjit Waghmode
---
V2 Changes:
- Added error handling condition for newly added features
---
drivers/spi/spi.c | 8
include/linux/spi/spi.h | 11 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index cf8b91b..22e8e7f 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1828,6 +1828,14 @@ static int __spi_validate(struct spi_device *spi, struct
spi_message *message)
if (list_empty(&message->transfers))
return -EINVAL;
+ /*
+* Data stripe option is selected if and only if when
+* two chips are enabled
+*/
+ if ((master->flags & SPI_MASTER_DATA_STRIPE)
+ && !(master->flags & SPI_MASTER_BOTH_CS))
+ return -EINVAL;
+
/* Half-duplex links include original MicroWire, and ones with
* only one data pin like SPI_3WIRE (switches direction) or where
* either MOSI or MISO is missing. They can also be caused by
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index d673072..53d3bc6 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -355,6 +355,17 @@ struct spi_master {
#define SPI_MASTER_NO_TX BIT(2) /* can't do buffer write */
#define SPI_MASTER_MUST_RX BIT(3) /* requires rx */
#define SPI_MASTER_MUST_TX BIT(4) /* requires tx */
+ /* Controller may support data stripe feature when more than one
+* chips are present.
+* Setting data stripe will send data in following manner:
+* -> even bytes i.e. 0, 2, 4,... are transmitted on lower data bus
+* -> odd bytes i.e. 1, 3, 5,.. are transmitted on upper data bus
+*/
+#define SPI_MASTER_DATA_STRIPE BIT(7) /* support data stripe
*/
+ /* Controller may support more than one chip.
+* This flag will enable that feature.
+*/
+#define SPI_MASTER_BOTH_CS BIT(8) /* enable both chips */
/* lock and mutex for SPI bus locking */
spinlock_t bus_lock_spinlock;
--
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/
Re: [PATCH 09/10] scsi: ufs: return value of pwr_change_notify
On Fri, Aug 21, 2015 at 2:58 PM, Alim Akhtar wrote:
> From: Seungwon Jeon
>
> Behavior of the "powwer mode change" contains vendor specific
s/powwer/power
> operation known as pwr_change_notify. This change adds return
> for pwr_change_notify to find success or failure.
>
> Signed-off-by: Seungwon Jeon
> Signed-off-by: Alim Akhtar
> ---
> drivers/scsi/ufs/ufshcd.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 8982da9..142a927 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -2579,14 +2579,18 @@ static int ufshcd_change_power_mode(struct ufs_hba
> *hba,
> dev_err(hba->dev,
> "%s: power mode change failed %d\n", __func__, ret);
> } else {
> - if (hba->vops && hba->vops->pwr_change_notify)
> - hba->vops->pwr_change_notify(hba,
> - POST_CHANGE, NULL, pwr_mode);
> + if (hba->vops && hba->vops->pwr_change_notify) {
> + ret = hba->vops->pwr_change_notify(hba,
> + POST_CHANGE, NULL, pwr_mode);
> + if (ret)
> + goto out;
> + }
>
> memcpy(&hba->pwr_info, pwr_mode,
> sizeof(struct ufs_pa_layer_attr));
> }
>
> +out:
> return ret;
> }
>
> @@ -2601,14 +2605,18 @@ int ufshcd_config_pwr_mode(struct ufs_hba *hba,
> struct ufs_pa_layer_attr final_params = { 0 };
> int ret;
>
> - if (hba->vops && hba->vops->pwr_change_notify)
> - hba->vops->pwr_change_notify(hba,
> -PRE_CHANGE, desired_pwr_mode, &final_params);
> - else
> + if (hba->vops && hba->vops->pwr_change_notify) {
> + ret = hba->vops->pwr_change_notify(hba,
> + PRE_CHANGE, desired_pwr_mode, &final_params);
> + if (ret)
> + goto out;
> + } else {
> memcpy(&final_params, desired_pwr_mode, sizeof(final_params));
> + }
>
> ret = ufshcd_change_power_mode(hba, &final_params);
>
> +out:
> return ret;
> }
> EXPORT_SYMBOL_GPL(ufshcd_config_pwr_mode);
> --
> 1.7.10.4
>
> --
> 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/
--
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 08/10] scsi: ufs: make ufshcd_config_pwr_mode of non-static func
On Fri, Aug 21, 2015 at 2:57 PM, Alim Akhtar wrote:
> From: Seungwon Jeon
>
> It can be used in the vendor's driver for the specific purpose.
more description of this log will be useful.
>
> Signed-off-by: Seungwon Jeon
> Signed-off-by: Alim Akhtar
> ---
> drivers/scsi/ufs/ufshcd.c |5 ++---
> drivers/scsi/ufs/ufshcd.h |2 ++
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index d425ea1..8982da9 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -185,8 +185,6 @@ static int ufshcd_uic_hibern8_ctrl(struct ufs_hba *hba,
> bool en);
> static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);
> static int ufshcd_host_reset_and_restore(struct ufs_hba *hba);
> static irqreturn_t ufshcd_intr(int irq, void *__hba);
> -static int ufshcd_config_pwr_mode(struct ufs_hba *hba,
> - struct ufs_pa_layer_attr *desired_pwr_mode);
> static int ufshcd_change_power_mode(struct ufs_hba *hba,
> struct ufs_pa_layer_attr *pwr_mode);
>
> @@ -2597,7 +2595,7 @@ static int ufshcd_change_power_mode(struct ufs_hba *hba,
> * @hba: per-adapter instance
> * @desired_pwr_mode: desired power configuration
> */
> -static int ufshcd_config_pwr_mode(struct ufs_hba *hba,
> +int ufshcd_config_pwr_mode(struct ufs_hba *hba,
> struct ufs_pa_layer_attr *desired_pwr_mode)
> {
> struct ufs_pa_layer_attr final_params = { 0 };
> @@ -2613,6 +2611,7 @@ static int ufshcd_config_pwr_mode(struct ufs_hba *hba,
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(ufshcd_config_pwr_mode);
>
> /**
> * ufshcd_complete_dev_init() - checks device readiness
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 045968e..13368e1 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -636,6 +636,8 @@ extern int ufshcd_dme_set_attr(struct ufs_hba *hba, u32
> attr_sel,
>u8 attr_set, u32 mib_val, u8 peer);
> extern int ufshcd_dme_get_attr(struct ufs_hba *hba, u32 attr_sel,
>u32 *mib_val, u8 peer);
> +extern int ufshcd_config_pwr_mode(struct ufs_hba *hba,
> + struct ufs_pa_layer_attr *desired_pwr_mode);
>
> /* UIC command interfaces for DME primitives */
> #define DME_LOCAL 0
> --
> 1.7.10.4
>
> --
> 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/
--
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 07/10] scsi: ufs: add add specific callback for hibern8
On Fri, Aug 21, 2015 at 2:57 PM, Alim Akhtar wrote:
> From: Seungwon Jeon
>
> Some host controller needs specific handling before/after
> (un)hibernation, This change adds specific callback function
> to support vendor's implementation.
>
> Signed-off-by: Seungwon Jeon
> Signed-off-by: Alim Akhtar
> ---
> drivers/scsi/ufs/ufshcd.c | 36
> drivers/scsi/ufs/ufshcd.h |3 +++
> 2 files changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index bc27f5e..d425ea1 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -181,8 +181,7 @@ static int ufshcd_probe_hba(struct ufs_hba *hba);
> static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
> bool skip_ref_clk);
> static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
> -static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba);
> -static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);
> +static int ufshcd_uic_hibern8_ctrl(struct ufs_hba *hba, bool en);
> static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);
> static int ufshcd_host_reset_and_restore(struct ufs_hba *hba);
> static irqreturn_t ufshcd_intr(int irq, void *__hba);
> @@ -215,6 +214,16 @@ static inline void ufshcd_disable_irq(struct ufs_hba
> *hba)
> }
> }
>
> +static inline int ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
> +{
> + return ufshcd_uic_hibern8_ctrl(hba, true);
> +}
> +
> +static inline int ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
> +{
> + return ufshcd_uic_hibern8_ctrl(hba, false);
> +}
> +
> /*
> * ufshcd_wait_for_register - wait for register value to change
> * @hba - per-adapter interface
> @@ -2395,7 +2404,7 @@ out:
> return ret;
> }
>
> -static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
> +static int __ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
> {
> struct uic_command uic_cmd = {0};
>
> @@ -2404,7 +2413,7 @@ static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
> return ufshcd_uic_pwr_ctrl(hba, &uic_cmd);
> }
>
> -static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
> +static int __ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
> {
> struct uic_command uic_cmd = {0};
> int ret;
> @@ -2419,6 +2428,25 @@ static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
> return ret;
> }
>
> +static int ufshcd_uic_hibern8_ctrl(struct ufs_hba *hba, bool en)
> +{
> + int ret;
> +
> + if (hba->vops && hba->vops->hibern8_notify)
> + hba->vops->hibern8_notify(hba, en, PRE_CHANGE);
Return of hibern8_notify is not checked. Otherwise make the return type void.
> +
> + ret = en ? __ufshcd_uic_hibern8_enter(hba) :
> + __ufshcd_uic_hibern8_exit(hba);
> + if (ret)
> + goto out;
> +
> + if (hba->vops && hba->vops->hibern8_notify)
> + hba->vops->hibern8_notify(hba, en, POST_CHANGE);
> +
> +out:
> + return ret;
> +}
> +
> /**
> * ufshcd_init_pwr_info - setting the POR (power on reset)
> * values in hba power info
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 0b7dde0..045968e 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -260,6 +260,8 @@ struct ufs_pwr_mode_info {
> * @specify_nexus_t_xfer_req:
> * @specify_nexus_t_tm_req: called before command is issued to allow vendor
> * specific handling to be set for nexus type.
> + * @hibern8_notify: called before and after hibernate/unhibernate is carried
> out
> + * to allow vendor spesific implementation.
> * @suspend: called during host controller PM callback
> * @resume: called during host controller PM callback
> */
> @@ -276,6 +278,7 @@ struct ufs_hba_variant_ops {
> int (*pwr_change_notify)(struct ufs_hba *,
> bool, struct ufs_pa_layer_attr *,
> struct ufs_pa_layer_attr *);
> + int (*hibern8_notify)(struct ufs_hba *, bool, bool);
> void(*specify_nexus_t_xfer_req)(struct ufs_hba *,
> int, struct scsi_cmnd *);
> void(*specify_nexus_t_tm_req)(struct ufs_hba *, int, u8);
> --
> 1.7.10.4
>
> --
> 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/
--
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: Problems loading firmware using built-in drivers with kernels that use initramfs.
> -Original Message- > From: Takashi Iwai [mailto:ti...@suse.de] > Sent: Wednesday, August 26, 2015 1:33 PM > To: Jie, Yang > Cc: Dmitry Torokhov; Luis R. Rodriguez; Girdwood, Liam R; > joonas.lahti...@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; Greg > Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis > Rodriguez; lkml > Subject: Re: Problems loading firmware using built-in drivers with kernels > that use initramfs. > > On Wed, 26 Aug 2015 07:12:46 +0200, > Jie, Yang wrote: > > > > > -Original Message- > > > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > > > Sent: Wednesday, August 26, 2015 3:58 AM > > > To: Takashi Iwai > > > Cc: Luis R. Rodriguez; Girdwood, Liam R; Jie, Yang; > > > joonas.lahti...@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; > > > Greg Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; > > > Luis Rodriguez; lkml > > > Subject: Re: Problems loading firmware using built-in drivers with > > > kernels that use initramfs. > > > > > > On Tue, Aug 25, 2015 at 12:46 PM, Takashi Iwai wrote: > > > > On Tue, 25 Aug 2015 21:34:08 +0200, Luis R. Rodriguez wrote: > > > >> > > > >> On Tue, Aug 25, 2015 at 10:17:00AM +0100, David Woodhouse wrote: > > > >> > Luis, did you tell me the other day that you made the kernel > > > >> > get firmware directly from the file system? This regression > > > >> > would be yours > > > then? > > > >> > > > >> I didn't implement that, Linus did in 2012 (see commit > > > >> abb139e75c2c titled > > > >> "firmware: teach the kernel to load firmware files directly from > > > >> the filesystem"). But we used to fallback to a userspace helper > > > >> when the fw was not present and then Takashi made this optional > > > >> via commit 7b1269f778782d titled "firmware: Make user-mode helper > optional". > > > >> Takashi noted in the Kconfig "The user-mode helper is no longer > > > >> required unless you have a special firmware file that resides in > > > >> a non-standard path". It was not clarified why that's true > > > >> though, or what you'd need to do to ensure that the fw would be > > > >> available. It would be good for us to elaborate on that. > > > > > > > > The recent udev already dropped the firmware loading feature. > > > > > > Note that even when we had udev helper to load the firmware it was > > > not always reliable depending on the exact point where we requested > firmware. > > > If request happened in probe() path before we mounted root fs then > > > we'd never get it loaded because we'd be waiting for devices settle > > > before mounting rootfs. > > > > For request in probe(), is it possible to use > > request_firmware_nowait() to wait rootfs mounted or timeout in another > thread? > > > > It looks usermodehelper_disabled is 0(at probe()) at this case then no > > waiting occurs here in our testing. > > It's possible -- and even with the normal request_firmware(), in theory. The > missing piece is that you need to inform the helper to retry the f/w loading. > Currently the direct f/w loader assumes that the file is there and returns > error if not present. > > If we implement a retry, another question is how to trigger it, i.e. how the > helper can know when a fs is mounted a new file is present. Got it, thanks Takashi and all. So looks we should(and already done for most audio firmware) implement it as Dmitry and Linus proposed, that is to make sure request_firmware() calls are not in driver's probe() paths. Yalin help posted sample code for this implementation(to request firmware in device node open) and actually I also did similar for Broadwell ADSP driver and will send out later, thank you all. Thanks, ~Keyon > > > Takashi -- 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 04/10] scsi: ufs: add quirk not to allow reset of interrupt aggregation
Few comments below,
On Fri, Aug 21, 2015 at 2:57 PM, Alim Akhtar wrote:
> From: Seungwon Jeon
>
> Some host controller supports interrupt aggregation, but doesn't
> allow to reset counter and timer by s/w.
>
> Signed-off-by: Seungwon Jeon
> Signed-off-by: Alim Akhtar
> ---
> drivers/scsi/ufs/ufshcd.c |3 ++-
> drivers/scsi/ufs/ufshcd.h |6 ++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index b441a39..35380aa 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -3204,7 +3204,8 @@ static void ufshcd_transfer_req_compl(struct ufs_hba
> *hba)
> * false interrupt if device completes another request after resetting
> * aggregation and before reading the DB.
> */
> - if (ufshcd_is_intr_aggr_allowed(hba))
> + if (ufshcd_is_intr_aggr_allowed(hba) &&
> + !(hba->quirks & UFSHCI_QUIRK_BROKEN_RESET_INTR_AGGR))
How about to rename this quirk as UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR as
there are some drawbacks about the existing method also as per the
comments above. Or this can be also put as opts instead as quirk.
> ufshcd_reset_intr_aggr(hba);
>
> tr_doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 24245c9..7986a54 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -471,6 +471,12 @@ struct ufs_hba {
> */
> #define UFSHCI_QUIRK_BROKEN_REQ_LIST_CLRUFS_BIT(7)
>
> + /*
> +* This quirk needs to be enabled if host controller doesn't allow
> +* that the interrupt aggregation timer and counter are reset by s/w.
> +*/
> + #define UFSHCI_QUIRK_BROKEN_RESET_INTR_AGGR UFS_BIT(8)
> +
> unsigned int quirks;/* Deviations from standard UFSHCI spec. */
>
> wait_queue_head_t tm_wq;
> --
> 1.7.10.4
>
> --
> 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/
--
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] mmc: block: disable the reliable write If the card does not support CMD23
Hi Uffe,
The bool variable do_rel_wr is used on line 1408 and line 1436:
if (brq->data.blocks> 1 || do_rel_wr) {
/* SPI multiblock writes terminate using a special
* token, not a STOP_TRANSMISSION request.
*/
if (do_rel_wr)
mmc_apply_rel_rw(brq, card, req);
If a card does not support CMD23, I think we need to set the do_rel_wr to false
at the beginning of this mmc_blk_rw_rq_prep function
Thanks,
Yong Li
> Date: Tue, 25 Aug 2015 14:06:43 +0200
> Subject: Re: [PATCH] mmc: block: disable the reliable write If the card does
> not support CMD23
> From: ulf.hans...@linaro.org
> To: sdliy...@gmail.com
> CC: ch...@printf.net; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
>
> On 14 August 2015 at 09:30, wrote:
>> From: Yong Li
>>
>> Signed-off-by: Yong Li
>> ---
>> drivers/mmc/card/block.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>> index 452782b..d9e3c45 100644
>> --- a/drivers/mmc/card/block.c
>> +++ b/drivers/mmc/card/block.c
>> @@ -1366,7 +1366,8 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req
>> *mqrq,
>> bool do_rel_wr = ((req->cmd_flags & REQ_FUA) ||
>> (req->cmd_flags & REQ_META)) &&
>> (rq_data_dir(req) == WRITE) &&
>> - (md->flags & MMC_BLK_REL_WR);
>> + (md->flags & MMC_BLK_REL_WR) &&
>> + !(card->quirks & MMC_QUIRK_BLK_NO_CMD23);
>
> Further down in mmc_blk_rw_rq_prep() we check for
> MMC_QUIRK_BLK_NO_CMD23. That check becomes redundant after this
> change, please remove that check as a part of this patch as well.
>
>>
>> memset(brq, 0, sizeof(struct mmc_blk_request));
>> brq->mrq.cmd = &brq->cmd;
>> --
>> 2.1.0
>>
>
> Kind regards
> Uffe
--
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 02/10] scsi: ufs: add quirk to contain unconformable utrd field
Few minor comments below,
On Fri, Aug 21, 2015 at 2:57 PM, Alim Akhtar wrote:
> From: Seungwon Jeon
>
> UTRD(UTP Transfer Request Descriptor)'s field such as offset/length,
> especially response's has DWORD expression. This quirk can be specified
> for host controller not to conform standard.
>
> Signed-off-by: Seungwon Jeon
> Signed-off-by: Alim Akhtar
> ---
> drivers/scsi/ufs/ufshcd.c | 28 +---
> drivers/scsi/ufs/ufshcd.h |7 +++
> 2 files changed, 28 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index b0ade73..f882bf0 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -1009,7 +1009,7 @@ ufshcd_send_uic_cmd(struct ufs_hba *hba, struct
> uic_command *uic_cmd)
> *
> * Returns 0 in case of success, non-zero value in case of failure
> */
> -static int ufshcd_map_sg(struct ufshcd_lrb *lrbp)
> +static int ufshcd_map_sg(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
> {
> struct ufshcd_sg_entry *prd_table;
> struct scatterlist *sg;
> @@ -1023,8 +1023,13 @@ static int ufshcd_map_sg(struct ufshcd_lrb *lrbp)
> return sg_segments;
>
> if (sg_segments) {
> - lrbp->utr_descriptor_ptr->prd_table_length =
> - cpu_to_le16((u16) (sg_segments));
> + if (hba->quirks & UFSHCI_QUIRK_BROKEN_UTRD)
> + lrbp->utr_descriptor_ptr->prd_table_length =
> + cpu_to_le16((u16)(sg_segments *
> + sizeof(struct ufshcd_sg_entry)));
> + else
> + lrbp->utr_descriptor_ptr->prd_table_length =
> + cpu_to_le16((u16) (sg_segments));
>
> prd_table = (struct ufshcd_sg_entry *)lrbp->ucd_prdt_ptr;
>
> @@ -1347,7 +1352,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
> struct scsi_cmnd *cmd)
>
> /* form UPIU before issuing the command */
> ufshcd_compose_upiu(hba, lrbp);
> - err = ufshcd_map_sg(lrbp);
> + err = ufshcd_map_sg(hba, lrbp);
> if (err) {
> lrbp->cmd = NULL;
> clear_bit_unlock(tag, &hba->lrb_in_use);
> @@ -2035,12 +2040,21 @@ static void ufshcd_host_memory_configure(struct
> ufs_hba *hba)
>
> cpu_to_le32(upper_32_bits(cmd_desc_element_addr));
>
> /* Response upiu and prdt offset should be in double words */
This comment can be moved below for the else case.
> - utrdlp[i].response_upiu_offset =
> + if (hba->quirks & UFSHCI_QUIRK_BROKEN_UTRD) {
> + utrdlp[i].response_upiu_offset =
> + cpu_to_le16(response_offset);
> + utrdlp[i].prd_table_offset =
> + cpu_to_le16(prdt_offset);
> + utrdlp[i].response_upiu_length =
> + cpu_to_le16(ALIGNED_UPIU_SIZE);
> + } else {
> + utrdlp[i].response_upiu_offset =
> cpu_to_le16((response_offset >> 2));
> - utrdlp[i].prd_table_offset =
> + utrdlp[i].prd_table_offset =
> cpu_to_le16((prdt_offset >> 2));
> - utrdlp[i].response_upiu_length =
> + utrdlp[i].response_upiu_length =
> cpu_to_le16(ALIGNED_UPIU_SIZE >> 2);
> + }
>
> hba->lrb[i].utr_descriptor_ptr = (utrdlp + i);
> hba->lrb[i].ucd_req_ptr =
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index c40a0e7..1fa5ac1 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -459,6 +459,13 @@ struct ufs_hba {
> */
> #define UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION UFS_BIT(5)
>
> + /*
> +* This quirk needs to be enabled if host controller doesn't conform
> +* with UTRD. Some fields such as offset/length might not be in
> double word,
> +* but in byte.
> +*/
> + #define UFSHCI_QUIRK_BROKEN_UTRDUFS_BIT(6)
This macro name may be given more meaningful name such as
UFSHCI_QUIRK_BYTE_ALIGN_UTRD or something similar.
> +
> unsigned int quirks;/* Deviations from standard UFSHCI spec. */
>
> wait_queue_head_t tm_wq;
> --
> 1.7.10.4
>
> --
> 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/
--
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/major
[PATCH v16 10/16] perf, tools, jevents: Add support for long descriptions
Implement support in jevents to parse long descriptions for events
that may have them in the JSON files. A follow on patch will make this
long description available to user through the 'perf list' command.
Signed-off-by: Andi Kleen
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
Changelog[v14]
- [Jiri Olsa] Break up independent parts of the patch into
separate patches.
---
tools/perf/pmu-events/jevents.c| 31 +++
tools/perf/pmu-events/jevents.h|3 ++-
tools/perf/pmu-events/pmu-events.h |1 +
3 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index 5f7603b..a8507c9 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -203,7 +203,7 @@ static void print_events_table_prefix(FILE *fp, const char
*tblname)
}
static int print_events_table_entry(void *data, char *name, char *event,
- char *desc)
+ char *desc, char *long_desc)
{
FILE *outfp = data;
/*
@@ -215,6 +215,8 @@ static int print_events_table_entry(void *data, char *name,
char *event,
fprintf(outfp, "\t.name = \"%s\",\n", name);
fprintf(outfp, "\t.event = \"%s\",\n", event);
fprintf(outfp, "\t.desc = \"%s\",\n", desc);
+ if (long_desc && long_desc[0])
+ fprintf(outfp, "\t.long_desc = \"%s\",\n", long_desc);
fprintf(outfp, "},\n");
@@ -235,7 +237,8 @@ static void print_events_table_suffix(FILE *outfp)
/* Call func with each event in the json file */
int json_events(const char *fn,
- int (*func)(void *data, char *name, char *event, char *desc),
+ int (*func)(void *data, char *name, char *event, char *desc,
+ char *long_desc),
void *data)
{
int err = -EIO;
@@ -254,6 +257,8 @@ int json_events(const char *fn,
tok = tokens + 1;
for (i = 0; i < tokens->size; i++) {
char *event = NULL, *desc = NULL, *name = NULL;
+ char *long_desc = NULL;
+ char *extra_desc = NULL;
struct msrmap *msr = NULL;
jsmntok_t *msrval = NULL;
jsmntok_t *precise = NULL;
@@ -279,6 +284,9 @@ int json_events(const char *fn,
} else if (json_streq(map, field, "BriefDescription")) {
addfield(map, &desc, "", "", val);
fixdesc(desc);
+ } else if (json_streq(map, field, "PublicDescription"))
{
+ addfield(map, &long_desc, "", "", val);
+ fixdesc(long_desc);
} else if (json_streq(map, field, "PEBS") && nz) {
precise = val;
} else if (json_streq(map, field, "MSRIndex") && nz) {
@@ -287,10 +295,10 @@ int json_events(const char *fn,
msrval = val;
} else if (json_streq(map, field, "Errata") &&
!json_streq(map, val, "null")) {
- addfield(map, &desc, ". ",
+ addfield(map, &extra_desc, ". ",
" Spec update: ", val);
} else if (json_streq(map, field, "Data_LA") && nz) {
- addfield(map, &desc, ". ",
+ addfield(map, &extra_desc, ". ",
" Supports address when precise",
NULL);
}
@@ -298,19 +306,26 @@ int json_events(const char *fn,
}
if (precise && !strstr(desc, "(Precise Event)")) {
if (json_streq(map, precise, "2"))
- addfield(map, &desc, " ", "(Must be precise)",
- NULL);
+ addfield(map, &extra_desc, " ",
+ "(Must be precise)", NULL);
else
- addfield(map, &desc, " ",
+ addfield(map, &extra_desc, " ",
"(Precise event)", NULL);
}
+ if (desc && extra_desc)
+ addfield(map, &desc, " ", extra_desc, NULL);
+ if (long_desc && extra_desc)
+ addfield(map, &long_desc, " ", extra_desc, NULL);
if (msr != NULL)
addfield(map, &event, ",", msr->pname, msrval);
fixname(name);
- err = func(data, name, event, desc);
+
+ err = func(data, name, event, desc, long_desc);
free(event);
fr
Re: [PATCH] Memory hot added,The memory can not been added to movable zone
On 26.8.2015 2:36, Changsheng Liu wrote: > > > 在 2015/8/25 19:13, Vlastimil Babka 写道: >> On 08/25/2015 12:25 PM, Changsheng Liu wrote: >>> Thanks very much for your review, I can move the memory from normal zone >>> to movable zone succesfully. >>> And thank you for let me understand the memory mechanism better. >>> 在 2015/8/25 3:15, Yasuaki Ishimatsu 写道: >> >> So you agree to drop the patch from -mm? > The system add memory to normal zone defaultly so that it can be > used by kernel and then we can not move the memory to movable zone. > The patch can add the memory to movable zone directlly. I thought that you confirmed that the following works? echo online_movable > /sys/devices/system/memory/memoryXXX/state If you want it to be the default, there's the node_movable kernel boot option. Does it work for you? -- 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 v16 12/16] perf, tools: Support long descriptions with perf list
Previously we were dropping the useful longer descriptions that some
events have in the event list completely. This patch makes them appear with
perf list.
Old perf list:
baclears:
baclears.all
[Counts the number of baclears]
vs new:
perf list -v:
...
baclears:
baclears.all
[The BACLEARS event counts the number of times the front end is
resteered, mainly when the Branch Prediction Unit cannot provide
a correct prediction and this is corrected by the Branch Address
Calculator at the front end. The BACLEARS.ANY event counts the
number of baclears for any type of branch]
Signed-off-by: Andi Kleen
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
Changelog[v15]
- [Jir Olsa, Andi Kleen] Fix usage strings; update man page.
Changelog[v14]
- [Jiri Olsa] Break up independent parts of the patch into
separate patches.
---
tools/perf/Documentation/perf-list.txt |6 +-
tools/perf/builtin-list.c | 13 +
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/tools/perf/Documentation/perf-list.txt
b/tools/perf/Documentation/perf-list.txt
index 9507552..48202f2 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -8,7 +8,7 @@ perf-list - List all symbolic event types
SYNOPSIS
[verse]
-'perf list' [--no-desc] [hw|sw|cache|tracepoint|pmu|event_glob]
+'perf list' [--no-desc] [--long-desc] [hw|sw|cache|tracepoint|pmu|event_glob]
DESCRIPTION
---
@@ -20,6 +20,10 @@ OPTIONS
--no-desc::
Don't print descriptions.
+-v::
+--long-desc::
+Print longer event descriptions.
+
[[EVENT_MODIFIERS]]
EVENT MODIFIERS
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 3f058f7..f800927 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -22,14 +22,17 @@ int cmd_list(int argc, const char **argv, const char
*prefix __maybe_unused)
{
int i;
bool raw_dump = false;
+ bool long_desc_flag = false;
struct option list_options[] = {
OPT_BOOLEAN(0, "raw-dump", &raw_dump, "Dump raw events"),
OPT_BOOLEAN('d', "desc", &desc_flag,
"Print extra event descriptions. --no-desc to not
print."),
+ OPT_BOOLEAN('v', "long-desc", &long_desc_flag,
+ "Print longer event descriptions."),
OPT_END()
};
const char * const list_usage[] = {
- "perf list [--no-desc] [hw|sw|cache|tracepoint|pmu|event_glob]",
+ "perf list [] [hw|sw|cache|tracepoint|pmu|event_glob]",
NULL
};
@@ -44,7 +47,7 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
printf("\nList of pre-defined events (to be used in -e):\n\n");
if (argc == 0) {
- print_events(NULL, raw_dump, !desc_flag);
+ print_events(NULL, raw_dump, !desc_flag, long_desc_flag);
return 0;
}
@@ -63,13 +66,15 @@ int cmd_list(int argc, const char **argv, const char
*prefix __maybe_unused)
strcmp(argv[i], "hwcache") == 0)
print_hwcache_events(NULL, raw_dump);
else if (strcmp(argv[i], "pmu") == 0)
- print_pmu_events(NULL, raw_dump, !desc_flag);
+ print_pmu_events(NULL, raw_dump, !desc_flag,
+ long_desc_flag);
else {
char *sep = strchr(argv[i], ':'), *s;
int sep_idx;
if (sep == NULL) {
- print_events(argv[i], raw_dump, !desc_flag);
+ print_events(argv[i], raw_dump, !desc_flag,
+ long_desc_flag);
continue;
}
sep_idx = sep - argv[i];
--
1.7.9.5
--
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 v16 09/16] perf, tools: Add override support for event list CPUID
From: Andi Kleen
Add a PERF_CPUID variable to override the CPUID of the current CPU (within
the current architecture). This is useful for testing, so that all event
lists can be tested on a single system.
Signed-off-by: Andi Kleen
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
v2: Fix double free in earlier version.
Print actual CPUID being used with verbose option.
---
tools/perf/util/pmu.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index e4cb21e..ca01aea 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -477,10 +477,16 @@ static int pmu_add_cpu_aliases(struct list_head *head)
struct pmu_event *pe;
char *cpuid;
- cpuid = get_cpuid_str();
+ cpuid = getenv("PERF_CPUID");
+ if (cpuid)
+ cpuid = strdup(cpuid);
+ if (!cpuid)
+ cpuid = get_cpuid_str();
if (!cpuid)
return 0;
+ pr_debug("Using CPUID %s\n", cpuid);
+
i = 0;
while (1) {
map = &pmu_events_map[i++];
--
1.7.9.5
--
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 v16 05/16] perf, tools: Support CPU id matching for x86 v2
From: Andi Kleen
Implement the code to match CPU types to mapfile types for x86
based on CPUID. This extends an existing similar function,
but changes it to use the x86 mapfile cpu description.
This allows to resolve event lists generated by jevents.
Signed-off-by: Andi Kleen
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
v2: Update to new get_cpuid_str() interface
---
tools/perf/arch/x86/util/header.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/tools/perf/arch/x86/util/header.c
b/tools/perf/arch/x86/util/header.c
index 146d12a..a74a48d 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -19,8 +19,8 @@ cpuid(unsigned int op, unsigned int *a, unsigned int *b,
unsigned int *c,
: "a" (op));
}
-int
-get_cpuid(char *buffer, size_t sz)
+static int
+__get_cpuid(char *buffer, size_t sz, const char *fmt)
{
unsigned int a, b, c, d, lvl;
int family = -1, model = -1, step = -1;
@@ -48,7 +48,7 @@ get_cpuid(char *buffer, size_t sz)
if (family >= 0x6)
model += ((a >> 16) & 0xf) << 4;
}
- nb = scnprintf(buffer, sz, "%s,%u,%u,%u$", vendor, family, model, step);
+ nb = scnprintf(buffer, sz, fmt, vendor, family, model, step);
/* look for end marker to ensure the entire data fit */
if (strchr(buffer, '$')) {
@@ -57,3 +57,21 @@ get_cpuid(char *buffer, size_t sz)
}
return -1;
}
+
+int
+get_cpuid(char *buffer, size_t sz)
+{
+ return __get_cpuid(buffer, sz, "%s,%u,%u,%u$");
+}
+
+char *
+get_cpuid_str(void)
+{
+ char *buf = malloc(128);
+
+ if (__get_cpuid(buf, 128, "%s-%u-%X$") < 0) {
+ free(buf);
+ return NULL;
+ }
+ return buf;
+}
--
1.7.9.5
--
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 v16 01/16] perf, tools: Add jsmn `jasmine' JSON parser
From: Andi Kleen
I need a JSON parser. This adds the simplest JSON
parser I could find -- Serge Zaitsev's jsmn `jasmine' --
to the perf library. I merely converted it to (mostly)
Linux style and added support for non 0 terminated input.
The parser is quite straight forward and does not
copy any data, just returns tokens with offsets
into the input buffer. So it's relatively efficient
and simple to use.
The code is not fully checkpatch clean, but I didn't
want to completely fork the upstream code.
Original source: http://zserge.bitbucket.org/jsmn.html
In addition I added a simple wrapper that mmaps a json
file and provides some straight forward access functions.
Used in follow-on patches to parse event files.
Acked-by: Namhyung Kim
Acked-by: Jiri Olsa
Signed-off-by: Andi Kleen
Signed-off-by: Sukadev Bhattiprolu
---
v2: Address review feedback.
v3: Minor checkpatch fixes.
v4 (by Sukadev Bhattiprolu)
- Rebase to 4.0 and fix minor conflicts in tools/perf/Makefile.perf
- Report error if specified events file is invalid.
v5 (Sukadev Bhattiprolu)
- Move files to tools/perf/pmu-events/ since parsing of JSON file
now occurs when _building_ rather than running perf.
---
tools/perf/pmu-events/jsmn.c | 313 ++
tools/perf/pmu-events/jsmn.h | 67 +
tools/perf/pmu-events/json.c | 162 ++
tools/perf/pmu-events/json.h | 36 +
4 files changed, 578 insertions(+)
create mode 100644 tools/perf/pmu-events/jsmn.c
create mode 100644 tools/perf/pmu-events/jsmn.h
create mode 100644 tools/perf/pmu-events/json.c
create mode 100644 tools/perf/pmu-events/json.h
diff --git a/tools/perf/pmu-events/jsmn.c b/tools/perf/pmu-events/jsmn.c
new file mode 100644
index 000..11d1fa1
--- /dev/null
+++ b/tools/perf/pmu-events/jsmn.c
@@ -0,0 +1,313 @@
+/*
+ * Copyright (c) 2010 Serge A. Zaitsev
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ * Slightly modified by AK to not assume 0 terminated input.
+ */
+
+#include
+#include "jsmn.h"
+
+/*
+ * Allocates a fresh unused token from the token pool.
+ */
+static jsmntok_t *jsmn_alloc_token(jsmn_parser *parser,
+ jsmntok_t *tokens, size_t num_tokens)
+{
+ jsmntok_t *tok;
+
+ if ((unsigned)parser->toknext >= num_tokens)
+ return NULL;
+ tok = &tokens[parser->toknext++];
+ tok->start = tok->end = -1;
+ tok->size = 0;
+ return tok;
+}
+
+/*
+ * Fills token type and boundaries.
+ */
+static void jsmn_fill_token(jsmntok_t *token, jsmntype_t type,
+ int start, int end)
+{
+ token->type = type;
+ token->start = start;
+ token->end = end;
+ token->size = 0;
+}
+
+/*
+ * Fills next available token with JSON primitive.
+ */
+static jsmnerr_t jsmn_parse_primitive(jsmn_parser *parser, const char *js,
+ size_t len,
+ jsmntok_t *tokens, size_t num_tokens)
+{
+ jsmntok_t *token;
+ int start;
+
+ start = parser->pos;
+
+ for (; parser->pos < len; parser->pos++) {
+ switch (js[parser->pos]) {
+#ifndef JSMN_STRICT
+ /*
+* In strict mode primitive must be followed by ","
+* or "}" or "]"
+*/
+ case ':':
+#endif
+ case '\t':
+ case '\r':
+ case '\n':
+ case ' ':
+ case ',':
+ case ']':
+ case '}':
+ goto found;
+ default:
+ break;
+ }
+ if (js[parser->pos] < 32 || js[parser->pos] >= 127) {
+ parser->pos = start;
+ return JSMN_ERROR_INVAL;
+ }
+ }
+#ifdef JSMN_STRICT
+ /*
+* In strict mode p
[PATCH v16 08/16] perf, tools: Add a --no-desc flag to perf list
From: Andi Kleen
Add a --no-desc flag to perf list to not print the event descriptions
that were earlier added for JSON events. This may be useful to
get a less crowded listing.
It's still default to print descriptions as that is the more useful
default for most users.
Signed-off-by: Andi Kleen
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
v2: Rename --quiet to --no-desc. Add option to man page.
---
tools/perf/Documentation/perf-list.txt |8 +++-
tools/perf/builtin-list.c | 12
tools/perf/util/parse-events.c |4 ++--
tools/perf/util/parse-events.h |2 +-
tools/perf/util/pmu.c |4 ++--
tools/perf/util/pmu.h |2 +-
6 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/tools/perf/Documentation/perf-list.txt
b/tools/perf/Documentation/perf-list.txt
index bada893..9507552 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -8,13 +8,19 @@ perf-list - List all symbolic event types
SYNOPSIS
[verse]
-'perf list' [hw|sw|cache|tracepoint|pmu|event_glob]
+'perf list' [--no-desc] [hw|sw|cache|tracepoint|pmu|event_glob]
DESCRIPTION
---
This command displays the symbolic event types which can be selected in the
various perf commands with the -e option.
+OPTIONS
+---
+--no-desc::
+Don't print descriptions.
+
+
[[EVENT_MODIFIERS]]
EVENT MODIFIERS
---
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index af5bd05..3f058f7 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -16,16 +16,20 @@
#include "util/pmu.h"
#include "util/parse-options.h"
+static bool desc_flag = true;
+
int cmd_list(int argc, const char **argv, const char *prefix __maybe_unused)
{
int i;
bool raw_dump = false;
struct option list_options[] = {
OPT_BOOLEAN(0, "raw-dump", &raw_dump, "Dump raw events"),
+ OPT_BOOLEAN('d', "desc", &desc_flag,
+ "Print extra event descriptions. --no-desc to not
print."),
OPT_END()
};
const char * const list_usage[] = {
- "perf list [hw|sw|cache|tracepoint|pmu|event_glob]",
+ "perf list [--no-desc] [hw|sw|cache|tracepoint|pmu|event_glob]",
NULL
};
@@ -40,7 +44,7 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
printf("\nList of pre-defined events (to be used in -e):\n\n");
if (argc == 0) {
- print_events(NULL, raw_dump);
+ print_events(NULL, raw_dump, !desc_flag);
return 0;
}
@@ -59,13 +63,13 @@ int cmd_list(int argc, const char **argv, const char
*prefix __maybe_unused)
strcmp(argv[i], "hwcache") == 0)
print_hwcache_events(NULL, raw_dump);
else if (strcmp(argv[i], "pmu") == 0)
- print_pmu_events(NULL, raw_dump);
+ print_pmu_events(NULL, raw_dump, !desc_flag);
else {
char *sep = strchr(argv[i], ':'), *s;
int sep_idx;
if (sep == NULL) {
- print_events(argv[i], raw_dump);
+ print_events(argv[i], raw_dump, !desc_flag);
continue;
}
sep_idx = sep - argv[i];
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index d826e6f..5a4aed7 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1668,7 +1668,7 @@ out_enomem:
/*
* Print the help text for the event symbols:
*/
-void print_events(const char *event_glob, bool name_only)
+void print_events(const char *event_glob, bool name_only, bool quiet_flag)
{
print_symbol_events(event_glob, PERF_TYPE_HARDWARE,
event_symbols_hw, PERF_COUNT_HW_MAX, name_only);
@@ -1678,7 +1678,7 @@ void print_events(const char *event_glob, bool name_only)
print_hwcache_events(event_glob, name_only);
- print_pmu_events(event_glob, name_only);
+ print_pmu_events(event_glob, name_only, quiet_flag);
if (event_glob != NULL)
return;
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index a09b0e2..c0ee03b 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -138,7 +138,7 @@ void parse_events_update_lists(struct list_head *list_event,
void parse_events_evlist_error(struct parse_events_evlist *data,
int idx, const char *str);
-void print_events(const char *event_glob, bool name_only);
+void print_events(const char *event_glob, bool name_only, bool quiet);
struct event_symbol {
const char *s
[PATCH v16 13/16] perf, tools, jevents: Add support for event topics
Allow assigning categories "Topics" field to the PMU events i.e.
process the topic field from the JSON file and add a corresponding
topic field to the generated C events tables.
Signed-off-by: Andi Kleen
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
Changelog[v14]
[Jiri Olsa] Move this independent code off into a separate patch.
---
tools/perf/pmu-events/jevents.c| 12 +---
tools/perf/pmu-events/jevents.h|2 +-
tools/perf/pmu-events/pmu-events.h |1 +
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index a8507c9..ea3474b 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -203,7 +203,7 @@ static void print_events_table_prefix(FILE *fp, const char
*tblname)
}
static int print_events_table_entry(void *data, char *name, char *event,
- char *desc, char *long_desc)
+ char *desc, char *long_desc, char *topic)
{
FILE *outfp = data;
/*
@@ -217,6 +217,8 @@ static int print_events_table_entry(void *data, char *name,
char *event,
fprintf(outfp, "\t.desc = \"%s\",\n", desc);
if (long_desc && long_desc[0])
fprintf(outfp, "\t.long_desc = \"%s\",\n", long_desc);
+ if (topic)
+ fprintf(outfp, "\t.topic = \"%s\",\n", topic);
fprintf(outfp, "},\n");
@@ -238,7 +240,7 @@ static void print_events_table_suffix(FILE *outfp)
/* Call func with each event in the json file */
int json_events(const char *fn,
int (*func)(void *data, char *name, char *event, char *desc,
- char *long_desc),
+ char *long_desc, char *topic),
void *data)
{
int err = -EIO;
@@ -259,6 +261,7 @@ int json_events(const char *fn,
char *event = NULL, *desc = NULL, *name = NULL;
char *long_desc = NULL;
char *extra_desc = NULL;
+ char *topic = NULL;
struct msrmap *msr = NULL;
jsmntok_t *msrval = NULL;
jsmntok_t *precise = NULL;
@@ -297,6 +300,8 @@ int json_events(const char *fn,
!json_streq(map, val, "null")) {
addfield(map, &extra_desc, ". ",
" Spec update: ", val);
+ } else if (json_streq(map, field, "Topic")) {
+ addfield(map, &topic, "", "", val);
} else if (json_streq(map, field, "Data_LA") && nz) {
addfield(map, &extra_desc, ". ",
" Supports address when precise",
@@ -320,12 +325,13 @@ int json_events(const char *fn,
addfield(map, &event, ",", msr->pname, msrval);
fixname(name);
- err = func(data, name, event, desc, long_desc);
+ err = func(data, name, event, desc, long_desc, topic);
free(event);
free(desc);
free(name);
free(long_desc);
free(extra_desc);
+ free(topic);
if (err)
break;
tok += j;
diff --git a/tools/perf/pmu-events/jevents.h b/tools/perf/pmu-events/jevents.h
index b0eb274..9ffcb89 100644
--- a/tools/perf/pmu-events/jevents.h
+++ b/tools/perf/pmu-events/jevents.h
@@ -3,7 +3,7 @@
int json_events(const char *fn,
int (*func)(void *data, char *name, char *event, char *desc,
- char *long_desc),
+ char *long_desc, char *topic),
void *data);
char *get_cpu_str(void);
diff --git a/tools/perf/pmu-events/pmu-events.h
b/tools/perf/pmu-events/pmu-events.h
index 711f049..6b69f4b 100644
--- a/tools/perf/pmu-events/pmu-events.h
+++ b/tools/perf/pmu-events/pmu-events.h
@@ -9,6 +9,7 @@ struct pmu_event {
const char *event;
const char *desc;
const char *long_desc;
+ const char *topic;
};
/*
--
1.7.9.5
--
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 v16 11/16] perf, tools: Add alias support for long descriptions
Previously we were dropping the useful longer descriptions that some
events have in the event list completely. Now that jevents provides
support for longer descriptions (see previous patch), add support for
parsing the long descriptions
Signed-off-by: Andi Kleen
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
Changelog[v14]
- [Jiri Olsa] Break up independent parts of the patch into
separate patches.
---
tools/perf/util/parse-events.c |5 +++--
tools/perf/util/parse-events.h |3 ++-
tools/perf/util/pmu.c | 15 ++-
tools/perf/util/pmu.h |4 +++-
4 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 5a4aed7..e14ceb6 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1668,7 +1668,8 @@ out_enomem:
/*
* Print the help text for the event symbols:
*/
-void print_events(const char *event_glob, bool name_only, bool quiet_flag)
+void print_events(const char *event_glob, bool name_only, bool quiet_flag,
+ bool long_desc)
{
print_symbol_events(event_glob, PERF_TYPE_HARDWARE,
event_symbols_hw, PERF_COUNT_HW_MAX, name_only);
@@ -1678,7 +1679,7 @@ void print_events(const char *event_glob, bool name_only,
bool quiet_flag)
print_hwcache_events(event_glob, name_only);
- print_pmu_events(event_glob, name_only, quiet_flag);
+ print_pmu_events(event_glob, name_only, quiet_flag, long_desc);
if (event_glob != NULL)
return;
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index c0ee03b..e468931 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -138,7 +138,8 @@ void parse_events_update_lists(struct list_head *list_event,
void parse_events_evlist_error(struct parse_events_evlist *data,
int idx, const char *str);
-void print_events(const char *event_glob, bool name_only, bool quiet);
+void print_events(const char *event_glob, bool name_only, bool quiet,
+ bool long_desc);
struct event_symbol {
const char *symbol;
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index ca01aea..e608ccc 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -210,7 +210,7 @@ static int perf_pmu__parse_snapshot(struct perf_pmu_alias
*alias,
}
static int __perf_pmu__new_alias(struct list_head *list, char *dir, char *name,
-char *desc, char *val)
+char *desc, char *val, char *long_desc)
{
struct perf_pmu_alias *alias;
int ret;
@@ -243,6 +243,8 @@ static int __perf_pmu__new_alias(struct list_head *list,
char *dir, char *name,
}
alias->desc = desc ? strdup(desc) : NULL;
+ alias->long_desc = long_desc ? strdup(long_desc) :
+ desc ? strdup(desc) : NULL;
list_add_tail(&alias->list, list);
@@ -260,7 +262,7 @@ static int perf_pmu__new_alias(struct list_head *list, char
*dir, char *name, FI
buf[ret] = 0;
- return __perf_pmu__new_alias(list, dir, name, NULL, buf);
+ return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL);
}
static inline bool pmu_alias_info_file(char *name)
@@ -508,7 +510,8 @@ static int pmu_add_cpu_aliases(struct list_head *head)
/* need type casts to override 'const' */
__perf_pmu__new_alias(head, NULL, (char *)pe->name,
- (char *)pe->desc, (char *)pe->event);
+ (char *)pe->desc, (char *)pe->event,
+ (char *)pe->long_desc);
}
out:
@@ -1077,7 +1080,8 @@ static void wordwrap(char *s, int start, int max, int
corr)
}
}
-void print_pmu_events(const char *event_glob, bool name_only, bool quiet_flag)
+void print_pmu_events(const char *event_glob, bool name_only, bool quiet_flag,
+ bool long_desc)
{
struct perf_pmu *pmu;
struct perf_pmu_alias *alias;
@@ -1124,7 +1128,8 @@ void print_pmu_events(const char *event_glob, bool
name_only, bool quiet_flag)
if (!aliases[j].name)
goto out_enomem;
- aliases[j].desc = alias->desc;
+ aliases[j].desc = long_desc ? alias->long_desc :
+ alias->desc;
j++;
}
if (pmu->selectable) {
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 42999c7..1aa614e 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -39,6 +39,7 @@ struct perf_pmu_info {
struct perf_pmu_alias {
char *name;
char *desc;
+ char *long_desc;
struct list_head terms; /* HEAD struct parse_e
[PATCH v16 07/16] perf, tools: Query terminal width and use in perf list
From: Andi Kleen
Automatically adapt the now wider and word wrapped perf list
output to wider terminals. This requires querying the terminal
before the auto pager takes over, and exporting this
information from the pager subsystem.
Signed-off-by: Andi Kleen
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Namhyung Kim
Acked-by: Jiri Olsa
---
tools/perf/util/cache.h |1 +
tools/perf/util/pager.c | 15 +++
tools/perf/util/pmu.c |3 ++-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/cache.h b/tools/perf/util/cache.h
index c861373..8e0d4b8 100644
--- a/tools/perf/util/cache.h
+++ b/tools/perf/util/cache.h
@@ -32,6 +32,7 @@ extern const char *perf_config_dirname(const char *, const
char *);
extern void setup_pager(void);
extern int pager_in_use(void);
extern int pager_use_color;
+int pager_get_columns(void);
char *alias_lookup(const char *alias);
int split_cmdline(char *cmdline, const char ***argv);
diff --git a/tools/perf/util/pager.c b/tools/perf/util/pager.c
index 53ef006..1770c88 100644
--- a/tools/perf/util/pager.c
+++ b/tools/perf/util/pager.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "run-command.h"
#include "sigchain.h"
+#include
/*
* This is split up from the rest of git so that we can do
@@ -8,6 +9,7 @@
*/
static int spawned_pager;
+static int pager_columns;
static void pager_preexec(void)
{
@@ -47,9 +49,12 @@ static void wait_for_pager_signal(int signo)
void setup_pager(void)
{
const char *pager = getenv("PERF_PAGER");
+ struct winsize sz;
if (!isatty(1))
return;
+ if (ioctl(1, TIOCGWINSZ, &sz) == 0)
+ pager_columns = sz.ws_col;
if (!pager)
pager = getenv("PAGER");
if (!(pager || access("/usr/bin/pager", X_OK)))
@@ -93,3 +98,13 @@ int pager_in_use(void)
env = getenv("PERF_PAGER_IN_USE");
return env ? perf_config_bool("PERF_PAGER_IN_USE", env) : 0;
}
+
+int pager_get_columns(void)
+{
+ char *s;
+
+ s = getenv("COLUMNS");
+ if (s)
+ return atoi(s);
+ return (pager_columns ? pager_columns : 80) - 2;
+}
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index cb0396e..0f10fa3 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -14,6 +14,7 @@
#include "cpumap.h"
#include "header.h"
#include "pmu-events/pmu-events.h"
+#include "cache.h"
struct perf_pmu_format {
char *name;
@@ -1079,7 +1080,7 @@ void print_pmu_events(const char *event_glob, bool
name_only)
int len, j;
struct pair *aliases;
int numdesc = 0;
- int columns = 78;
+ int columns = pager_get_columns();
pmu = NULL;
len = 0;
--
1.7.9.5
--
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 v16 16/16] perf, tools: Add README for info on parsing JSON/map files
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
tools/perf/pmu-events/README | 122 ++
1 file changed, 122 insertions(+)
create mode 100644 tools/perf/pmu-events/README
diff --git a/tools/perf/pmu-events/README b/tools/perf/pmu-events/README
new file mode 100644
index 000..da57cb5
--- /dev/null
+++ b/tools/perf/pmu-events/README
@@ -0,0 +1,122 @@
+
+The contents of this directory allow users to specify PMU events in
+their CPUs by their symbolic names rather than raw event codes (see
+example below).
+
+The main program in this directory, is the 'jevents', which is built and
+executed _before_ the perf binary itself is built.
+
+The 'jevents' program tries to locate and process JSON files in the directory
+tree tools/perf/pmu-events/arch/foo.
+
+ - Regular files with '.json' extension in the name are assumed to be
+ JSON files, each of which describes a set of PMU events.
+
+ - Regular files with basename starting with 'mapfile.csv' are assumed
+ to be a CSV file that maps a specific CPU to its set of PMU events.
+ (see below for mapfile format)
+
+ - Directories are traversed, but all other files are ignored.
+
+Using the JSON files and the mapfile, 'jevents' generates the C source file,
+'pmu-events.c', which encodes the two sets of tables:
+
+ - Set of 'PMU events tables' for all known CPUs in the architecture,
+ (one table like the following, per JSON file; table name 'pme_power8'
+ is derived from JSON file name, 'power8.json').
+
+ struct pmu_event pme_power8[] = {
+
+ ...
+
+ {
+ .name = "pm_1plus_ppc_cmpl",
+ .event = "event=0x100f2",
+ .desc = "1 or more ppc insts finished,",
+ },
+
+ ...
+ }
+
+ - A 'mapping table' that maps each CPU of the architecture, to its
+ 'PMU events table'
+
+ struct pmu_events_map pmu_events_map[] = {
+ {
+ .cpuid = "004b",
+ .version = "1",
+ .type = "core",
+ .table = pme_power8
+ },
+ ...
+
+ };
+
+After the 'pmu-events.c' is generated, it is compiled and the resulting
+'pmu-events.o' is added to 'libperf.a' which is then used to build perf.
+
+NOTES:
+ 1. Several CPUs can support same set of events and hence use a common
+ JSON file. Hence several entries in the pmu_events_map[] could map
+ to a single 'PMU events table'.
+
+ 2. The 'pmu-events.h' has an extern declaration for the mapping table
+ and the generated 'pmu-events.c' defines this table.
+
+ 3. _All_ known CPU tables for architecture are included in the perf
+ binary.
+
+At run time, perf determines the actual CPU it is running on, finds the
+matching events table and builds aliases for those events. This allows
+users to specify events by their name:
+
+ $ perf stat -e pm_1plus_ppc_cmpl sleep 1
+
+where 'pm_1plus_ppc_cmpl' is a Power8 PMU event.
+
+In case of errors when processing files in the tools/perf/pmu-events/arch
+directory, 'jevents' tries to create an empty mapping file to allow the perf
+build to succeed even if the PMU event aliases cannot be used.
+
+However some errors in processing may cause the perf build to fail.
+
+Mapfile format
+===
+
+The mapfile.csv format is expected to be:
+
+ Header line
+ CPUID,Version,File/path/name.json,Type
+
+where:
+
+ Comma:
+ is the required field delimiter (i.e other fields cannot
+ have commas within them).
+
+ Comments:
+ Lines in which the first character is either '\n' or '#'
+ are ignored.
+
+ Header line
+ The header line is the first line in the file, which is
+ _IGNORED_. It can be a comment (begin with '#') or empty.
+
+ CPUID:
+ CPUID is an arch-specific char string, that can be used
+ to identify CPU (and associate it with a set of PMU events
+ it supports). Multiple CPUIDS can point to the same
+ File/path/name.json.
+
+ Example:
+ CPUID == 'GenuineIntel-6-2E' (on x86).
+ CPUID == '004b0100' (PVR value in Powerpc)
+ Version:
+ is the Version of the mapfile.
+
+ File/path/name.json:
+ is the pathname for the JSON file, relative to the directory
+ containing the mapfile.csv
+
+ Type:
+ indicates whether the events or "core" or "uncore" events.
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...
[PATCH v16 14/16] perf, tools: Add support for event list topics
From: Andi Kleen
Add support to group the output of perf list by the Topic field
in the JSON file.
Example output:
% perf list
...
Cache:
l1d.replacement
[L1D data line replacements]
l1d_pend_miss.pending
[L1D miss oustandings duration in cycles]
l1d_pend_miss.pending_cycles
[Cycles with L1D load Misses outstanding]
l2_l1d_wb_rqsts.all
[Not rejected writebacks from L1D to L2 cache lines in any state]
l2_l1d_wb_rqsts.hit_e
[Not rejected writebacks from L1D to L2 cache lines in E state]
l2_l1d_wb_rqsts.hit_m
[Not rejected writebacks from L1D to L2 cache lines in M state]
...
Pipeline:
arith.fpu_div
[Divide operations executed]
arith.fpu_div_active
[Cycles when divider is busy executing divide operations]
baclears.any
[Counts the total number when the front end is resteered, mainly
when the BPU cannot provide a correct prediction and this is
corrected by other branch handling mechanisms at the front end]
br_inst_exec.all_branches
[Speculative and retired branches]
br_inst_exec.all_conditional
[Speculative and retired macro-conditional branches]
br_inst_exec.all_direct_jmp
[Speculative and retired macro-unconditional branches excluding
calls and indirects]
br_inst_exec.all_direct_near_call
[Speculative and retired direct near calls]
br_inst_exec.all_indirect_jump_non_call_ret
Signed-off-by: Andi Kleen
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
Changelog[v14]
- [Jiri Olsa] Move jevents support for Topic to a separate patch.
---
tools/perf/util/pmu.c | 37 +++--
tools/perf/util/pmu.h |1 +
2 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index e608ccc..75a53d3 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -210,7 +210,8 @@ static int perf_pmu__parse_snapshot(struct perf_pmu_alias
*alias,
}
static int __perf_pmu__new_alias(struct list_head *list, char *dir, char *name,
-char *desc, char *val, char *long_desc)
+char *desc, char *val, char *long_desc,
+char *topic)
{
struct perf_pmu_alias *alias;
int ret;
@@ -245,6 +246,7 @@ static int __perf_pmu__new_alias(struct list_head *list,
char *dir, char *name,
alias->desc = desc ? strdup(desc) : NULL;
alias->long_desc = long_desc ? strdup(long_desc) :
desc ? strdup(desc) : NULL;
+ alias->topic = topic ? strdup(topic) : NULL;
list_add_tail(&alias->list, list);
@@ -262,7 +264,7 @@ static int perf_pmu__new_alias(struct list_head *list, char
*dir, char *name, FI
buf[ret] = 0;
- return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL);
+ return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL, NULL);
}
static inline bool pmu_alias_info_file(char *name)
@@ -511,7 +513,7 @@ static int pmu_add_cpu_aliases(struct list_head *head)
/* need type casts to override 'const' */
__perf_pmu__new_alias(head, NULL, (char *)pe->name,
(char *)pe->desc, (char *)pe->event,
- (char *)pe->long_desc);
+ (char *)pe->long_desc, (char *)pe->topic);
}
out:
@@ -1042,19 +1044,26 @@ static char *format_alias_or(char *buf, int len, struct
perf_pmu *pmu,
return buf;
}
-struct pair {
+struct sevent {
char *name;
char *desc;
+ char *topic;
};
-static int cmp_pair(const void *a, const void *b)
+static int cmp_sevent(const void *a, const void *b)
{
- const struct pair *as = a;
- const struct pair *bs = b;
+ const struct sevent *as = a;
+ const struct sevent *bs = b;
/* Put extra events last */
if (!!as->desc != !!bs->desc)
return !!as->desc - !!bs->desc;
+ if (as->topic && bs->topic) {
+ int n = strcmp(as->topic, bs->topic);
+
+ if (n)
+ return n;
+ }
return strcmp(as->name, bs->name);
}
@@ -1088,9 +1097,10 @@ void print_pmu_events(const char *event_glob, bool
name_only, bool quiet_flag,
char buf[1024];
int printed = 0;
int len, j;
- struct pair *aliases;
+ struct sevent *aliases;
int numdesc = 0;
int columns = pager_get_columns();
+ char *topic = NULL;
pmu = NULL;
len = 0;
@@ -1100,7 +1110,7 @@ void print_pmu_events(const char *event_glob, bool
name_only, bool quiet_flag,
if (pmu->selectable)
len++;
}
- aliases = zalloc(sizeof(struct pair) * len);
+ aliases = zalloc(sizeof(struct sevent) * len);
if (!aliases)
goto out_enomem;
pmu = NUL
Re: [PATCH 01/10] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC
Hi,
Few minor comments,
On Fri, Aug 21, 2015 at 2:57 PM, Alim Akhtar wrote:
> From: Seungwon Jeon
>
> This patch introduces Exynos UFS PHY driver. This driver
> supports to deal with phy calibration and power control
> according to UFS host driver's behavior.
>
> Signed-off-by: Seungwon Jeon
> Signed-off-by: Alim Akhtar
> Cc: Kishon Vijay Abraham I
> ---
> .../devicetree/bindings/phy/samsung-phy.txt| 22 ++
> drivers/phy/Kconfig|7 +
> drivers/phy/Makefile |1 +
> drivers/phy/phy-exynos-ufs.c | 277
>
> drivers/phy/phy-exynos-ufs.h | 73 ++
> drivers/phy/phy-exynos7-ufs.h | 89 +++
> include/linux/phy/phy-exynos-ufs.h | 107
> 7 files changed, 576 insertions(+)
> create mode 100644 drivers/phy/phy-exynos-ufs.c
> create mode 100644 drivers/phy/phy-exynos-ufs.h
> create mode 100644 drivers/phy/phy-exynos7-ufs.h
> create mode 100644 include/linux/phy/phy-exynos-ufs.h
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index 60c6f2a..1abe2c4 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -174,3 +174,25 @@ Example:
> usbdrdphy0 = &usb3_phy0;
> usbdrdphy1 = &usb3_phy1;
> };
> +
> +Samsung Exynos7 soc serise UFS PHY Controller
> +-
> +
> +UFS PHY nodes are defined to describe on-chip UFS Physical layer controllers.
> +Each UFS PHY controller should have its own node.
> +
> +Required properties:
> +- compatible: compatible list, contains "samsung,exynos7-ufs-phy"
> +- reg : offset and length of the UFS PHY register set;
> +- reg-names : reg name(s) must be 'phy-pma';
> +- #phy-cells : must be zero
> +- samsung,syscon-phandle : a phandle to the PMU system controller, no
> arguments
> +
> +Example:
> + ufs_phy: ufs-phy@0x15571800 {
> + compatible = "samsung,exynos7-ufs-phy";
> + reg = <0x15571800 0x240>;
> + reg-names = "phy-pma";
> + samsung,syscon-phandle = <&pmu_system_controller>;
> + #phy-cells = <0>;
> + };
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 6b8dd16..7449376 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -358,4 +358,11 @@ config PHY_BRCMSTB_SATA
> Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs.
> Likely useful only with CONFIG_SATA_BRCMSTB enabled.
>
> +config PHY_EXYNOS_UFS
> + tristate "EXYNOS SoC series UFS PHY driver"
> + depends on OF && ARCH_EXYNOS
> + select GENERIC_PHY
> + help
> + Support for UFS PHY on Samsung EXYNOS chipsets.
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index f344e1b..7a36818 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -45,3 +45,4 @@ obj-$(CONFIG_PHY_QCOM_UFS)+= phy-qcom-ufs-qmp-14nm.o
> obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
> obj-$(CONFIG_PHY_BRCMSTB_SATA) += phy-brcmstb-sata.o
> obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
> +obj-$(CONFIG_PHY_EXYNOS_UFS) += phy-exynos-ufs.o
> diff --git a/drivers/phy/phy-exynos-ufs.c b/drivers/phy/phy-exynos-ufs.c
> new file mode 100644
> index 000..840375d
> --- /dev/null
> +++ b/drivers/phy/phy-exynos-ufs.c
> @@ -0,0 +1,277 @@
> +/*
> + * UFS PHY driver for Samsung EXYNOS SoC
> + *
> + * Copyright (C) 2015 Samsung Electronics Co., Ltd.
> + * Author: Seungwon Jeon
> + *
> + * 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 "phy-exynos-ufs.h"
> +
> +#define for_each_phy_lane(phy, i) \
> + for (i = 0; i < (phy)->lane_cnt; i++)
> +#define for_each_phy_cfg(cfg) \
> + for (; (cfg)->id; (cfg)++)
> +
> +#define phy_pma_writel(phy, val, reg) \
> + writel((val), (phy)->reg_pma + (reg))
> +#define phy_pma_readl(phy, reg) \
> + readl((phy)->reg_pma + (reg))
> +
> +#define PHY_DEF_LANE_CNT 1
> +
> +static inline struct exynos_ufs_phy *get_exynos_ufs_phy(struct phy *phy)
> +{
> + return (struct exynos_ufs_phy *)phy_get_drvdata(phy);
> +}
> +
> +static void exynos_ufs_phy_config(struct exynos_ufs_phy *phy,
> + const struct exynos_ufs_phy_cfg *cfg, u8 lane)
> +{
> + enum {LANE_0, LANE_1}; /* lane index */
> +
> + switch (l
[PATCH v16 15/16] perf, tools: Handle header line in mapfile
From: Andi Kleen
To work with existing mapfiles, assume that the first line in
'mapfile.csv' is a header line and skip over it.
Signed-off-by: Andi Kleen
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
Changelog[v2]
All architectures may not use the "Family" to identify. So,
assume first line is header.
---
tools/perf/pmu-events/jevents.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index ea3474b..7347cca 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -462,7 +462,12 @@ static int process_mapfile(FILE *outfp, char *fpath)
print_mapping_table_prefix(outfp);
- line_num = 0;
+ /* Skip first line (header) */
+ p = fgets(line, n, mapfp);
+ if (!p)
+ goto out;
+
+ line_num = 1;
while (1) {
char *cpuid, *version, *type, *fname;
@@ -506,8 +511,8 @@ static int process_mapfile(FILE *outfp, char *fpath)
fprintf(outfp, "},\n");
}
+out:
print_mapping_table_suffix(outfp);
-
return 0;
}
--
1.7.9.5
--
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 v16 06/16] perf, tools: Support alias descriptions
From: Andi Kleen
Add support to print alias descriptions in perf list, which
are taken from the generated event files.
The sorting code is changed to put the events with descriptions
at the end. The descriptions are printed as possibly multiple word
wrapped lines.
Example output:
% perf list
...
arith.fpu_div
[Divide operations executed]
arith.fpu_div_active
[Cycles when divider is busy executing divide operations]
Signed-off-by: Andi Kleen
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
Changelog
- Delete a redundant free()
Changelog[v14]
- [Jiri Olsa] Fail, rather than continue if strdup() returns NULL;
remove unnecessary __maybe_unused.
---
tools/perf/util/pmu.c | 82 +++--
tools/perf/util/pmu.h |1 +
2 files changed, 67 insertions(+), 16 deletions(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index b8f7627..cb0396e 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -209,7 +209,7 @@ static int perf_pmu__parse_snapshot(struct perf_pmu_alias
*alias,
}
static int __perf_pmu__new_alias(struct list_head *list, char *dir, char *name,
-char *desc __maybe_unused, char *val)
+char *desc, char *val)
{
struct perf_pmu_alias *alias;
int ret;
@@ -241,6 +241,8 @@ static int __perf_pmu__new_alias(struct list_head *list,
char *dir, char *name,
perf_pmu__parse_snapshot(alias, dir, name);
}
+ alias->desc = desc ? strdup(desc) : NULL;
+
list_add_tail(&alias->list, list);
return 0;
@@ -1030,11 +1032,42 @@ static char *format_alias_or(char *buf, int len, struct
perf_pmu *pmu,
return buf;
}
-static int cmp_string(const void *a, const void *b)
+struct pair {
+ char *name;
+ char *desc;
+};
+
+static int cmp_pair(const void *a, const void *b)
+{
+ const struct pair *as = a;
+ const struct pair *bs = b;
+
+ /* Put extra events last */
+ if (!!as->desc != !!bs->desc)
+ return !!as->desc - !!bs->desc;
+ return strcmp(as->name, bs->name);
+}
+
+static void wordwrap(char *s, int start, int max, int corr)
{
- const char * const *as = a;
- const char * const *bs = b;
- return strcmp(*as, *bs);
+ int column = start;
+ int n;
+
+ while (*s) {
+ int wlen = strcspn(s, " \t");
+
+ if (column + wlen >= max && column > start) {
+ printf("\n%*s", start, "");
+ column = start + corr;
+ }
+ n = printf("%s%.*s", column > start ? " " : "", wlen, s);
+ if (n <= 0)
+ break;
+ s += wlen;
+ column += n;
+ while (isspace(*s))
+ s++;
+ }
}
void print_pmu_events(const char *event_glob, bool name_only)
@@ -1044,7 +1077,9 @@ void print_pmu_events(const char *event_glob, bool
name_only)
char buf[1024];
int printed = 0;
int len, j;
- char **aliases;
+ struct pair *aliases;
+ int numdesc = 0;
+ int columns = 78;
pmu = NULL;
len = 0;
@@ -1054,14 +1089,15 @@ void print_pmu_events(const char *event_glob, bool
name_only)
if (pmu->selectable)
len++;
}
- aliases = zalloc(sizeof(char *) * len);
+ aliases = zalloc(sizeof(struct pair) * len);
if (!aliases)
goto out_enomem;
pmu = NULL;
j = 0;
while ((pmu = perf_pmu__scan(pmu)) != NULL) {
list_for_each_entry(alias, &pmu->aliases, list) {
- char *name = format_alias(buf, sizeof(buf), pmu, alias);
+ char *name = alias->desc ? alias->name :
+ format_alias(buf, sizeof(buf), pmu, alias);
bool is_cpu = !strcmp(pmu->name, "cpu");
if (event_glob != NULL &&
@@ -1070,37 +1106,51 @@ void print_pmu_events(const char *event_glob, bool
name_only)
event_glob
continue;
- if (is_cpu && !name_only)
+ if (is_cpu && !name_only && !alias->desc)
name = format_alias_or(buf, sizeof(buf), pmu,
alias);
- aliases[j] = strdup(name);
- if (aliases[j] == NULL)
+ aliases[j].name = name;
+ if (is_cpu && !name_only && !alias->desc)
+ aliases[j].name = format_alias_or(buf,
sizeof(buf),
+ pmu, alias);
+ aliases[j].name = strdup(aliases[j].name);
+ if (!aliases[
[PATCH v16 04/16] perf, tools: Support CPU ID matching for Powerpc
Implement code that returns the generic CPU ID string for Powerpc.
This will be used to identify the specific table of PMU events to
parse/compare user specified events against.
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
Changelog[v14]
- [Jiri Olsa] Move this independent code off into a separate patch.
---
tools/perf/arch/powerpc/util/header.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tools/perf/arch/powerpc/util/header.c
b/tools/perf/arch/powerpc/util/header.c
index 6c1b8a7..65f9391 100644
--- a/tools/perf/arch/powerpc/util/header.c
+++ b/tools/perf/arch/powerpc/util/header.c
@@ -32,3 +32,14 @@ get_cpuid(char *buffer, size_t sz)
}
return -1;
}
+
+char *
+get_cpuid_str(void)
+{
+ char *bufp;
+
+ if (asprintf(&bufp, "%.8lx", mfspr(SPRN_PVR)) < 0)
+ bufp = NULL;
+
+ return bufp;
+}
--
1.7.9.5
--
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 v16 03/16] perf, tools: Use pmu_events table to create aliases
At run time (when 'perf' is starting up), locate the specific table
of PMU events that corresponds to the current CPU. Using that table,
create aliases for the each of the PMU events in the CPU. The use
these aliases to parse the user specified perf event.
In short this would allow the user to specify events using their
aliases rather than raw event codes.
Based on input and some earlier patches from Andi Kleen, Jiri Olsa.
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
Changelog[v4]
- Split off unrelated code into separate patches.
Changelog[v3]
- [Jiri Olsa] Fix memory leak in cpuid
Changelog[v2]
- [Andi Kleen] Replace pmu_events_map->vfm with a generic "cpuid".
---
tools/perf/util/header.h |1 +
tools/perf/util/pmu.c| 61 ++
2 files changed, 62 insertions(+)
diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index 9b53b65..10f4a24 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -158,4 +158,5 @@ int write_padded(int fd, const void *bf, size_t count,
size_t count_aligned);
*/
int get_cpuid(char *buffer, size_t sz);
+char *get_cpuid_str(void);
#endif /* __PERF_HEADER_H */
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 89c91a1..b8f7627 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -12,6 +12,8 @@
#include "pmu.h"
#include "parse-events.h"
#include "cpumap.h"
+#include "header.h"
+#include "pmu-events/pmu-events.h"
struct perf_pmu_format {
char *name;
@@ -449,6 +451,62 @@ static struct cpu_map *pmu_cpumask(const char *name)
return cpus;
}
+/*
+ * Return the CPU id as a raw string.
+ *
+ * Each architecture should provide a more precise id string that
+ * can be use to match the architecture's "mapfile".
+ */
+char * __weak get_cpuid_str(void)
+{
+ return NULL;
+}
+
+/*
+ * From the pmu_events_map, find the table of PMU events that corresponds
+ * to the current running CPU. Then, add all PMU events from that table
+ * as aliases.
+ */
+static int pmu_add_cpu_aliases(struct list_head *head)
+{
+ int i;
+ struct pmu_events_map *map;
+ struct pmu_event *pe;
+ char *cpuid;
+
+ cpuid = get_cpuid_str();
+ if (!cpuid)
+ return 0;
+
+ i = 0;
+ while (1) {
+ map = &pmu_events_map[i++];
+ if (!map->table)
+ goto out;
+
+ if (!strcmp(map->cpuid, cpuid))
+ break;
+ }
+
+ /*
+* Found a matching PMU events table. Create aliases
+*/
+ i = 0;
+ while (1) {
+ pe = &map->table[i++];
+ if (!pe->name)
+ break;
+
+ /* need type casts to override 'const' */
+ __perf_pmu__new_alias(head, NULL, (char *)pe->name,
+ (char *)pe->desc, (char *)pe->event);
+ }
+
+out:
+ free(cpuid);
+ return 0;
+}
+
struct perf_event_attr * __weak
perf_pmu__get_default_config(struct perf_pmu *pmu __maybe_unused)
{
@@ -473,6 +531,9 @@ static struct perf_pmu *pmu_lookup(const char *name)
if (pmu_aliases(name, &aliases))
return NULL;
+ if (!strcmp(name, "cpu"))
+ (void)pmu_add_cpu_aliases(&aliases);
+
if (pmu_type(name, &type))
return NULL;
--
1.7.9.5
--
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 v16 00/16] perf, tools: Add support for PMU events in JSON format
CPUs support a large number of performance monitoring events (PMU events) and often these events are very specific to an architecture/model of the CPU. To use most of these PMU events with perf, we currently have to identify them by their raw codes: perf stat -e r100f2 sleep 1 This patchset allows architectures to specify these PMU events in JSON files located in 'tools/perf/pmu-events/arch/' of the mainline tree. The events from the JSON files for the architecture are then built into the perf binary. At run time, perf identifies the specific set of events for the CPU and creates "event aliases". These aliases allow users to specify events by "name" as: perf stat -e pm_1plus_ppc_cmpl sleep 1 The file, 'tools/perf/pmu-events/README' in [PATCH 16/16] gives more details. Note: - All known events tables for the architecture are included in the perf binary. - For architectures that don't have any JSON files, an empty mapping table is created and they should continue to build. Thanks to input from Andi Kleen, Jiri Olsa, Namhyung Kim and Ingo Molnar. These patches are available from: https://github.com:sukadev/linux.git Branch Description -- json-v16Source Code only json-files-6x86 and Powerpc datafiles only json-v16-with-data Both code and data (for build/test) NOTE: Only "source code" patches (i.e those in json-v16) are being emailed. Please pull the "data files" from the json-files-6 branch. Changelog[v16] Rebase to recent perf/core; fix minor merge conflicts; drop 3 patches that were merged into perf/core. Changelog[v15] Code changes: - Fix 'perf list' usage string and update man page. - Remove a redundant __maybe_unused tag. - Rebase to recent perf/core branch. Data files updates: json-files-5 branch - Rebase to perf/intel-json-files-5 from Andi Kleen - Add patch from Madhavan Srinivasan for couple more Powerpc models Changelog[v14] Comments from Jiri Olsa: - Change parameter name/type for pmu_add_cpu_aliases (from void *data to list_head *head) - Use asprintf() in file_name_to_tablename() and simplify/reorg code. - Use __weak definition from - Use fopen() with mode "w" and eliminate unlink() - Remove minor TODO. - Add error check for return value from strdup() in print_pmu_events(). - Move independent changes from patches 3,11,12 .. to separate patches for easier review/backport. - Clarify mapfile's "header line support" in patch description. - Fix build failure with DEBUG=1 Comment from Andi Kleen: - In tools/perf/pmu-events/Build, check for 'mapfile.csv' rather than 'mapfile*' Misc: - Minor changes/clarifications to tools/perf/pmu-events/README. Changelog[v13] Version: Individual patches have their own history :-) that I am preserving. Patchset version (v13) is for overall patchset and is somewhat arbitrary. - Added support for "categories" of events to perf - Add mapfile, jevents build dependency on pmu-events.c - Silence jevents when parsing JSON files unless V=1 is specified - Cleanup error messages - Fix memory leak with ->cpuid - Rebase to Arnaldo's tree - Allow overriding CPUID via environment variable - Support long descriptions for events - Handle header line in mapfile.csv - Cleanup JSON files (trim PublicDescription if identical to/prefix of BriefDescription field) Andi Kleen (9): perf, tools: Add jsmn `jasmine' JSON parser perf, tools, jevents: Program to convert JSON file to C style file perf, tools: Support CPU id matching for x86 v2 perf, tools: Support alias descriptions perf, tools: Query terminal width and use in perf list perf, tools: Add a --no-desc flag to perf list perf, tools: Add override support for event list CPUID perf, tools: Add support for event list topics perf, tools: Handle header line in mapfile Sukadev Bhattiprolu (7): perf, tools: Use pmu_events table to create aliases perf, tools: Support CPU ID matching for Powerpc perf, tools, jevents: Add support for long descriptions perf, tools: Add alias support for long descriptions perf, tools: Support long descriptions with perf list perf, tools, jevents: Add support for event topics perf, tools: Add README for info on parsing JSON/map files tools/perf/Documentation/perf-list.txt | 12 +- tools/perf/Makefile.perf | 26 +- tools/perf/arch/powerpc/util/header.c | 11 + tools/perf/arch/x86/util/header.c | 24 +- tools/perf/builtin-list.c | 17 +- tools/perf/pmu-events/Build
[PATCH v16 02/16] perf, tools, jevents: Program to convert JSON file to C style file
From: Andi Kleen
This is a modified version of an earlier patch by Andi Kleen.
We expect architectures to describe the performance monitoring events
for each CPU in a corresponding JSON file, which look like:
[
{
"EventCode": "0x00",
"UMask": "0x01",
"EventName": "INST_RETIRED.ANY",
"BriefDescription": "Instructions retired from execution.",
"PublicDescription": "Instructions retired from execution.",
"Counter": "Fixed counter 1",
"CounterHTOff": "Fixed counter 1",
"SampleAfterValue": "203",
"SampleAfterValue": "203",
"MSRIndex": "0",
"MSRValue": "0",
"TakenAlone": "0",
"CounterMask": "0",
"Invert": "0",
"AnyThread": "0",
"EdgeDetect": "0",
"PEBS": "0",
"PRECISE_STORE": "0",
"Errata": "null",
"Offcore": "0"
}
]
We also expect the architectures to provide a mapping between individual
CPUs to their JSON files. Eg:
GenuineIntel-6-1E,V1,/NHM-EP/NehalemEP_core_V1.json,core
which maps each CPU, identified by [vendor, family, model, version, type]
to a JSON file.
Given these files, the program, jevents::
- locates all JSON files for the architecture,
- parses each JSON file and generates a C-style "PMU-events table"
(pmu-events.c)
- locates a mapfile for the architecture
- builds a global table, mapping each model of CPU to the
corresponding PMU-events table.
The 'pmu-events.c' is generated when building perf and added to libperf.a.
The global table pmu_events_map[] table in this pmu-events.c will be used
in perf in a follow-on patch.
If the architecture does not have any JSON files or there is an error in
processing them, an empty mapping file is created. This would allow the
build of perf to proceed even if we are not able to provide aliases for
events.
The parser for JSON files allows parsing Intel style JSON event files. This
allows to use an Intel event list directly with perf. The Intel event lists
can be quite large and are too big to store in unswappable kernel memory.
The conversion from JSON to C-style is straight forward. The parser knows
(very little) Intel specific information, and can be easily extended to
handle fields for other CPUs.
The parser code is partially shared with an independent parsing library,
which is 2-clause BSD licenced. To avoid any conflicts I marked those
files as BSD licenced too. As part of perf they become GPLv2.
Signed-off-by: Andi Kleen
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Jiri Olsa
---
v2: Address review feedback. Rename option to --event-files
v3: Add JSON example
v4: Update manpages.
v5: Don't remove dot in fixname. Fix compile error. Add include
protection. Comment realloc.
v6: Include debug/util.h
v7: (Sukadev Bhattiprolu)
Rebase to 4.0 and fix some conflicts.
v8: (Sukadev Bhattiprolu)
Move jevents.[hc] to tools/perf/pmu-events/
Rewrite to locate and process arch specific JSON and "map" files;
and generate a C file.
(Removed acked-by Namhyung Kim due to modest changes to patch)
Compile the generated pmu-events.c and add the pmu-events.o to
libperf.a
v9: [Sukadev Bhattiprolu/Andi Kleen] Rename ->vfm to ->cpuid and use
that field to encode the PVR in Power.
Allow blank lines in mapfile.
[Jiri Olsa] Pass ARCH as a parameter to jevents so we don't have
to detect it.
[Jiri Olsa] Use the infrastrastructure to build pmu-events/perf
(Makefile changes from Jiri included in this patch).
[Jiri Olsa, Andi Kleen] Detect changes to JSON files and rebuild
pmu-events.o only if necessary.
v11:- [Andi Kleen] Add mapfile, jevents dependency on pmu-events.c
- [Jiri Olsa] Be silient if arch doesn't have JSON files
- Also silence 'jevents' when parsing JSON files unless V=1 is
specified during build. Cleanup error messages.
v14:- - [Jiri Olsa] Fix compile error with DEBUG=1; drop unlink() and
use "w" mode with fopen(); simplify file_name_to_table_name()
v15:- Fix minor conflict in tools/perf/Makefile.perf when rebasing
to recent perf/core.
v16:- Rebase to upstream; fix conflicts in tools/perf/Makefile.perf
---
tools/perf/Makefile.perf | 26 +-
tools/perf/pmu-events/Build| 11 +
tools/perf/pmu-events/jevents.c| 686
tools/perf/pmu-events/jevents.h| 17 +
tools/perf/pmu-events/json.h |3 +
tools/perf/pmu-events/pmu-events.h | 35 ++
6 files changed, 774 insertions(+), 4 deletions(-)
create mode 100644 tools/perf/pmu-events/Build
create mode 100644 tools/perf/pmu-events/jevents.c
create mode 100644 tools/perf/pmu-events/jevents.h
create mode 100644 tools/perf/pmu-events/pmu-events.h
diff --git a/tools/perf/Makefile.perf b/tools/perf/Make
Re: [PATCH 0/5] usb: common and dwc3: converting to unified device property
On Tue, Aug 25, 2015 at 02:04:30PM +0300, Heikki Krogerus wrote: > Hi, > > While converting dwc3 to the unified device property interface, I > noticed that there is really nothing preventing of_usb_get_dr_mode and > of_usb_get_maximum_speed from being converted as well. Hope that's OK. > Place the reference for usb_get_dr_mode and usb_get_maximum_speed at otg.h and ch9.h may not be good, why not add a common.h which is at include/linux/usb/ too. > The only special case was dwc3-st.c, where the dr_mode is requested > before the platform device has been populated. I changed it so that > the dr_mode property is requested after the platform device is > populated in a separate patch. > > > Heikki Krogerus (5): > usb: common: of_usb_get_maximum_speed to usb_get_maximum_speed > usb: dwc3: st: prepare the driver for generic usb_get_dr_mode function > usb: common: of_usb_get_dr_mode to usb_get_dr_mode > usb: dwc3: core: convert to unified device property interface > usb: dwc3: pci: passing forward the ACPI companion > > drivers/usb/chipidea/core.c | 4 +-- > drivers/usb/common/common.c | 59 > +++-- > drivers/usb/dwc2/platform.c | 2 +- > drivers/usb/dwc3/core.c | 50 +- > drivers/usb/dwc3/dwc3-pci.c | 1 + > drivers/usb/dwc3/dwc3-st.c | 12 +++-- > drivers/usb/musb/musb_dsps.c| 2 +- > drivers/usb/musb/sunxi.c| 2 +- > drivers/usb/phy/phy-msm-usb.c | 2 +- > drivers/usb/phy/phy-tegra-usb.c | 2 +- > include/linux/usb/ch9.h | 11 +++- > include/linux/usb/of.h | 12 - > include/linux/usb/otg.h | 9 +++ > 13 files changed, 84 insertions(+), 84 deletions(-) > > -- > 2.5.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards, Peter Chen -- 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 V2 1/3] kvm: use kmalloc() instead of kzalloc() during iodev register/unregister
On 08/26/2015 01:45 PM, Joe Perches wrote: > On Wed, 2015-08-26 at 13:39 +0800, Jason Wang wrote: >> > >> > On 08/25/2015 11:29 PM, Joe Perches wrote: >>> > > On Tue, 2015-08-25 at 15:47 +0800, Jason Wang wrote: > > >> > All fields of kvm_io_range were initialized or copied explicitly > > >> > afterwards. So switch to use kmalloc(). >>> > > Is there any compiler added alignment padding >>> > > in either structure? If so, those padding >>> > > areas would now be uninitialized and may leak >>> > > kernel data if copied to user-space. >>> > > >> > I get your concern, but I don't a way to copy them to userspace, did you? > I didn't look. > > I just wanted you to be aware there's a difference > and a reason why kzalloc might be used even though > all structure members are initialized. > I see, thanks for the reminding. Looks like we are safe and I will add something like "kvm_io_range was never accessed by userspace" in the commit log if there's a new version. -- 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 V2 1/3] kvm: use kmalloc() instead of kzalloc() during iodev register/unregister
On Wed, 2015-08-26 at 13:39 +0800, Jason Wang wrote: > > On 08/25/2015 11:29 PM, Joe Perches wrote: > > On Tue, 2015-08-25 at 15:47 +0800, Jason Wang wrote: > >> > All fields of kvm_io_range were initialized or copied explicitly > >> > afterwards. So switch to use kmalloc(). > > Is there any compiler added alignment padding > > in either structure? If so, those padding > > areas would now be uninitialized and may leak > > kernel data if copied to user-space. > > > I get your concern, but I don't a way to copy them to userspace, did you? I didn't look. I just wanted you to be aware there's a difference and a reason why kzalloc might be used even though all structure members are initialized. -- 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 net-next] macvtap/macvlan: use IFF_NO_QUEUE
On 08/26/2015 12:32 AM, Vlad Yasevich wrote:
> On 08/25/2015 07:30 AM, Jason Wang wrote:
>>
>> On 08/25/2015 06:17 PM, Michael S. Tsirkin wrote:
>>> On Mon, Aug 24, 2015 at 04:33:12PM +0800, Jason Wang wrote:
> For macvlan, switch to use IFF_NO_QUEUE instead of tx_queue_len = 0.
>
> For macvtap, after commit 6acf54f1cf0a6747bac9fea26f34cfc5a9029523
> ("macvtap: Add support of packet capture on macvtap
> device."). Multiqueue macvtap suffers from single qdisc lock
> contention. This is because macvtap claims a non zero tx_queue_len and
> it reuses this value as it socket receive queue size.Thanks to
> IFF_NO_QUEUE, we can remove the lock contention without breaking
> existing socket receive queue length logic.
>
> Cc: Patrick McHardy
> Cc: Vladislav Yasevich
> Cc: Michael S. Tsirkin
> Signed-off-by: Jason Wang
>>> Seems to make sense. Give me a day or two to get over the jet lag
>>> (and get out from under the pile of mail accumulated while I was traveling),
>>> I'll review properly and ack.
>>>
>> A note on this patch: only default qdisc were removed but we don't lose
>> the ability to attach a qdisc to macvtap (though it may cause lock
>> contention on multiqueue case).
>>
> Wouldn't that lock contention be solved if we really had multiple queues
> for multi-queue macvtaps?
>
> -vlad
Yes, but this introduce another layer of txq locks contention? And it
also needs macvlan multiqueue support. We used to do something like this
but switch to NETIF_F_LLTX finally. You may refer:
2c11455321f37da6fe6cc36353149f9ac9183334 macvlan: add multiqueue capability
8ffab51b3dfc54876f145f15b351c41f3f703195 macvlan: lockless tx path
--
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] Use 2GB memory block size on large-memory x86-64 systems
On Tue, Aug 25, 2015 at 9:17 PM, Ingo Molnar wrote: > NAK due to lack of cleanliness: the two loops look almost identical - this > sure > can be factored out... Please check complete version at https://patchwork.kernel.org/patch/7074341/ Andrew, Ingo NAKed raw version of this patch, so you may need to remove it from -mm tree. Thanks Yinghai -- 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 v3] qcom: ipq40xx: Add basic board/dts support for IPQ40XX SoC
On Tue, Aug 25, 2015 at 02:14:05PM -0700, Stephen Boyd wrote:
> On 08/25, Varadarajan Narayanan wrote:
> > On Mon, Aug 24, 2015 at 03:49:28PM -0700, Stephen Boyd wrote:
> > > On 08/24, Varadarajan Narayanan wrote:
> >
> > > > + compatible = "qcom,ipq40xx-r3pc", "qcom,ipq40xx";
> > > > +
> > > > + memory {
> > > > + device_type = "memory";
> > > > + reg = <0x8000 0x2000>; /* 512MB */
> > > > + };
> > >
> > > Doesn't the bootloader fill the memory node for us? Why do we
> > > need this?
> > >
> > > > +
> > > > + chosen {
> > > > + bootargs = "root=/dev/ram rw init=/init
> > > > console=ttyMSM0,115200n8 initrd=0x8200,0x000E2246";
> > > > + };
> > >
> > > Please don't add bootargs. Use stdout-path for the console part
> > > and everything else should be done by the bootloader or is the
> > > defaults.
> >
> > Since this is for the emulation platform, we don't have the bootloader.
>
> Why are we upstreaming an emulation platform?
Ok, will skip this.
-Varada
> I assume you have some sort of scripts or something to load the
> kernel image into the emulator, so those scripts could go and
> modify the dtb in place to populate the initrd and commandline.
> If you need pointers on that feel free to contact me directly.
>
> >
> > > > + compatible = "arm,armv7-timer";
> > > > + interrupts = <1 2 0xf08>,
> > > > +<1 3 0xf08>,
> > > > +<1 4 0xf08>,
> > > > +<1 1 0xf08>;
> > > > + clock-frequency = <2083>;
> > >
> > > Drop this clock-frequency part if you can. The hardware should
> > > properly report the frequency.
> >
> > Cannot drop this. This is the ref-clock frequency. For the
> > chip it is 48MHz, for emulation is ~20MHz. Similar to
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/qcom-msm8974.dtsi#n89
>
> And the hardware is not emulated properly to report the actual
> frequency that the timer is running at? That's sad.
>
> At the least, this should be in the board specific dtsi file
> instead of the SoC specific file, because it's a board quirk.
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
--
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 V2 1/3] kvm: use kmalloc() instead of kzalloc() during iodev register/unregister
On 08/25/2015 11:29 PM, Joe Perches wrote: > On Tue, 2015-08-25 at 15:47 +0800, Jason Wang wrote: >> > All fields of kvm_io_range were initialized or copied explicitly >> > afterwards. So switch to use kmalloc(). > Is there any compiler added alignment padding > in either structure? If so, those padding > areas would now be uninitialized and may leak > kernel data if copied to user-space. > I get your concern, but I don't a way to copy them to userspace, did you? -- 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: Problems loading firmware using built-in drivers with kernels that use initramfs.
On Wed, 26 Aug 2015 07:12:46 +0200, Jie, Yang wrote: > > > -Original Message- > > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > > Sent: Wednesday, August 26, 2015 3:58 AM > > To: Takashi Iwai > > Cc: Luis R. Rodriguez; Girdwood, Liam R; Jie, Yang; > > joonas.lahti...@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; Greg > > Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis > > Rodriguez; lkml > > Subject: Re: Problems loading firmware using built-in drivers with kernels > > that use initramfs. > > > > On Tue, Aug 25, 2015 at 12:46 PM, Takashi Iwai wrote: > > > On Tue, 25 Aug 2015 21:34:08 +0200, > > > Luis R. Rodriguez wrote: > > >> > > >> On Tue, Aug 25, 2015 at 10:17:00AM +0100, David Woodhouse wrote: > > >> > Luis, did you tell me the other day that you made the kernel get > > >> > firmware directly from the file system? This regression would be yours > > then? > > >> > > >> I didn't implement that, Linus did in 2012 (see commit abb139e75c2c > > >> titled > > >> "firmware: teach the kernel to load firmware files directly from the > > >> filesystem"). But we used to fallback to a userspace helper when the > > >> fw was not present and then Takashi made this optional via commit > > >> 7b1269f778782d titled "firmware: Make user-mode helper optional". > > >> Takashi noted in the Kconfig "The user-mode helper is no longer > > >> required unless you have a special firmware file that resides in a > > >> non-standard path". It was not clarified why that's true though, or > > >> what you'd need to do to ensure that the fw would be available. It > > >> would be good for us to elaborate on that. > > > > > > The recent udev already dropped the firmware loading feature. > > > > Note that even when we had udev helper to load the firmware it was not > > always reliable depending on the exact point where we requested firmware. > > If request happened in probe() path before we mounted root fs then we'd > > never get it loaded because we'd be waiting for devices settle before > > mounting rootfs. > > For request in probe(), is it possible to use request_firmware_nowait() to > wait rootfs mounted or timeout in another thread? > > It looks usermodehelper_disabled is 0(at probe()) at this case then no > waiting occurs > here in our testing. It's possible -- and even with the normal request_firmware(), in theory. The missing piece is that you need to inform the helper to retry the f/w loading. Currently the direct f/w loader assumes that the file is there and returns error if not present. If we implement a retry, another question is how to trigger it, i.e. how the helper can know when a fs is mounted a new file is present. Takashi -- 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: Problems loading firmware using built-in drivers with kernels that use initramfs.
> On Aug 26, 2015, at 04:26, Linus Torvalds
> wrote:
>
> On Tue, Aug 25, 2015 at 12:58 PM, Dmitry Torokhov
> wrote:
>>
>> Either build firmware in the kernel or ramdisk (so it is always
>> available), or make sure request_firmware() calls are not in driver's
>> probe() paths.
>
> The correct answer is almost always that second one.
>
> Drivers that load firmware in their probe parts are generally doign
> things wrong.
>
> It's very occasionally the right thing to do - there are a few pieces
> of hardware where just about _everything_ about the device is in the
> firmware, and you simply can't even problem them before that, because
> you don't know what they *are* before the firmware has been loaded.
> The extreme case of that might be something like the base hardware
> being an FPGA that has a USB interface, but before the FPGA has been
> loaded, it basically has no identity. So there are probably valid
> cases in theory for loading firmware at probe time, but pretty much
> every single case I've ever actually seen, the probe knows what the
> actual hardware is from some identifiable piece, and the actual
> firmware loading should be delayed until the piece of hardware is
> actually opened.
>
> So the "load firmware in probe routine" happens, and we shouldn't
> disallow it, but it should be considered a "last resort" kind of
> thing.
>
> In general, things like sound drivers should *not* need to have their
> firmware in the initrd, even if you build them into the kernel. A disk
> driver? Yes. Maybe the root filesystem is on that disk, and you need
> the firmware for the disk driver to load it. But a sound device?
> Please just make sure that you load the firmware as late as possible.
>
i remember lots of drivers load their firmware when some user space process
open the device node, that is to say, they load the firmware in
->open() function, at this time , you can make sure the real filesystem is
ready in
most time.
i think your dsp firmware can also do like this.
you can refer to msm gnu driver:
static void load_gpu(struct drm_device *dev)
{
static DEFINE_MUTEX(init_lock);
struct msm_drm_private *priv = dev->dev_private;
mutex_lock(&init_lock);
if (!priv->gpu)
priv->gpu = adreno_load_gpu(dev);
mutex_unlock(&init_lock);
}
static int msm_open(struct drm_device *dev, struct drm_file *file)
{
struct msm_file_private *ctx;
/* For now, load gpu on open.. to avoid the requirement of having
* firmware in the initrd.
*/
load_gpu(dev);
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
file->driver_priv = ctx;
return 0;
}
it load the firmware in open() function.
Thanks
--
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 v9 0/3] Enable PPI sysfs interface for TPM 2.0
On Tue, Aug 25, 2015 at 07:20:24PM +0200, Peter Huewe wrote: > Will look at it as soon as possible - relocating to the us is quite > stressful.sorry about that. > > But since we are already at v9 i think it is in a good shape. > Peter Alright, thanks for informing about this! /Jarkko > Am 25. August 2015 19:03:27 MESZ, schrieb Jarkko Sakkinen > : > >Does this start be in the shape that there would be chance to pull this > >in at some point? To be able to enable TPM 2.0 chips from Linux is > >quite > >mandatory feature in my opinion. > > > >Thank you. > > > >/Jarkko > > > >On Wed, Aug 12, 2015 at 05:05:40PM +0300, Jarkko Sakkinen wrote: > >> v9: > >> * Fixed naming for __compat_only_sysfs_link_entry_to_kobj() > >> > >> v8: > >> * Renamed sysfs_link_entry_to_kobj() to > >> __compat_only_sysfs_link_entry_to_kobj() > >> > >> v7: > >> * Fixed compile error when CONFIG_SYSFS is not enabled. > >> > >> v6: > >> * Updated documentation. > >> > >> v5: > >> * Removed dangling export of kernfs_remove_by_name_ns() from the > >sysfs > >> patch. > >> > >> v4: > >> * Use sysfs_remove_link() > >> > >> v3: > >> * Fixed to_tpm_chip() macro. > >> * Split into two patches. > >> * Renamed sysfs_link_group_to_kobj to sysfs_link_entry_to_kobj > >> * Only create the "backwards compatibility" symlink for TPM 1.x > >devices. > >> > >> Jarkko Sakkinen (3): > >> sysfs: added __compat_only_sysfs_link_entry_to_kobj() > >> tpm: move the PPI attributes to character device directory. > >> tpm: update PPI documentation to address the location change. > >> > >> Documentation/ABI/testing/sysfs-driver-ppi | 19 - > >> drivers/char/tpm/tpm-chip.c| 24 ++-- > >> drivers/char/tpm/tpm.h | 17 > >> drivers/char/tpm/tpm_ppi.c | 34 > >--- > >> fs/sysfs/group.c | 44 > >++ > >> include/linux/sysfs.h | 11 > >> 6 files changed, 100 insertions(+), 49 deletions(-) > >> > >> -- > >> 2.5.0 > >> > > -- > Sent from my mobile -- 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: Proposal for finishing the 64-bit x86 syscall cleanup
>>> Thing 2: vdso compilation with binutils that doesn't support .cfi directives >>> >>> Userspace debuggers really like having the vdso properly >>> CFI-annotated, and the 32-bit fast syscall entries are annotatied >>> manually in hexidecimal. AFAIK Jan Beulich is the only person who >>> understands it. >>> >>> I want to be able to change the entries a little bit to clean them up >>> (and possibly rework the SYSCALL32 and SYSENTER register tricks, which >>> currently suck), but it's really, really messy right now because of >>> the hex CFI stuff. Could we just drop the CFI annotations if the >>> binutils version is too old or even just require new enough binutils >>> to build 32-bit and compat kernels? >> >> One thing I want to do is rework the 32-bit VDSO into a single image, >> using alternatives to handle the selection of entry method. The >> open-coded CFI crap has made that near impossible to do. >> > > Yes please! > > But please don't change the actual instruction ordering at all yet, > since the SYSCALL case seems to be buggy right now. > > (If you want to be really fancy, don't use alternatives. Instead > teach vdso2c to annotate the actual dynamic table function pointers so > we can rewrite the pointers at boot time. That will save a cycle or > two.) The easiest way to select the right entry code is by changing the ELF AUX vector. That gets the normal usage, but there are two additional cases that need addressing. 1) Some code could possibly lookup the __kernel_vsyscall symbol directly and call it, but that's non-standard. If there is code out there that does this, we could update the ELF symbol table to point __kernel_vsyscall to the chosen entry point, or just remove the symbol and let the caller fall back to INT80. 2) The sigreturn trampolines. These are tricky because the sigreturn syscalls implicitly uses regs->sp to find the signal frame. That interacts badly with the SYSENTER/SYSCALL entries, which save registers on the stack. It currently uses a bare SYSCALL instruction (no pushes to the stack), but falls back to INT80 for SYSENTER. One option is to create new syscalls that takes a pointer to the signal frame as arg1. -- Brian Gerst -- 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: Problems loading firmware using built-in drivers with kernels that use initramfs.
> -Original Message- > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > Sent: Wednesday, August 26, 2015 3:58 AM > To: Takashi Iwai > Cc: Luis R. Rodriguez; Girdwood, Liam R; Jie, Yang; > joonas.lahti...@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; Greg > Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis > Rodriguez; lkml > Subject: Re: Problems loading firmware using built-in drivers with kernels > that use initramfs. > > On Tue, Aug 25, 2015 at 12:46 PM, Takashi Iwai wrote: > > On Tue, 25 Aug 2015 21:34:08 +0200, > > Luis R. Rodriguez wrote: > >> > >> On Tue, Aug 25, 2015 at 10:17:00AM +0100, David Woodhouse wrote: > >> > Luis, did you tell me the other day that you made the kernel get > >> > firmware directly from the file system? This regression would be yours > then? > >> > >> I didn't implement that, Linus did in 2012 (see commit abb139e75c2c > >> titled > >> "firmware: teach the kernel to load firmware files directly from the > >> filesystem"). But we used to fallback to a userspace helper when the > >> fw was not present and then Takashi made this optional via commit > >> 7b1269f778782d titled "firmware: Make user-mode helper optional". > >> Takashi noted in the Kconfig "The user-mode helper is no longer > >> required unless you have a special firmware file that resides in a > >> non-standard path". It was not clarified why that's true though, or > >> what you'd need to do to ensure that the fw would be available. It > >> would be good for us to elaborate on that. > > > > The recent udev already dropped the firmware loading feature. > > Note that even when we had udev helper to load the firmware it was not > always reliable depending on the exact point where we requested firmware. > If request happened in probe() path before we mounted root fs then we'd > never get it loaded because we'd be waiting for devices settle before > mounting rootfs. For request in probe(), is it possible to use request_firmware_nowait() to wait rootfs mounted or timeout in another thread? It looks usermodehelper_disabled is 0(at probe()) at this case then no waiting occurs here in our testing. Thanks, ~Keyon > > Either build firmware in the kernel or ramdisk (so it is always available), or > make sure request_firmware() calls are not in driver's > probe() paths. > > Thanks. > > -- > Dmitry
[PATCH v2] mm: Check if section present during memory block (un)registering
Tony found on his setup, if memory block size 512M will cause crash
during booting.
BUG: unable to handle kernel paging request at ea007420
IP: [] get_nid_for_pfn+0x17/0x40
PGD 128ffcb067 PUD 128ffc9067 PMD 0
Oops: [#1] SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc8 #1
...
Call Trace:
[] ? register_mem_sect_under_node+0x66/0xe0
[] register_one_node+0x17b/0x240
[] ? pci_iommu_alloc+0x6e/0x6e
[] topology_init+0x3c/0x95
[] do_one_initcall+0xcd/0x1f0
The system has non continuous RAM address:
BIOS-e820: [mem 0x0013-0x001c] usable
BIOS-e820: [mem 0x001d7000-0x001ec7ffefff] usable
BIOS-e820: [mem 0x001f-0x002b] usable
BIOS-e820: [mem 0x002c1800-0x002d6fffefff] usable
BIOS-e820: [mem 0x002e-0x0039] usable
So there are start sections in memory block not present.
For example:
memory block : [0x2c1800, 0x2c2000) 512M
first three sections are not present.
Current register_mem_sect_under_node() assume first section is present,
but memory block section number range [start_section_nr, end_section_nr]
would include not present section.
For arch that support vmemmap, we don't setup memmap for struct page area
within not present sections area.
So skip the pfn range that belong to absent section.
Also fixes unregister_mem_sect_under_nodes() that assume one section per
memory block.
Reported-by: Tony Luck
Tested-by: Tony Luck
Fixes: bdee237c0343 ("x86: mm: Use 2GB memory block size on large memory x86-64
systems")
Fixes: 982792c782ef ("x86, mm: probe memory block size for generic x86 64bit")
Signed-off-by: Yinghai Lu
Cc: sta...@vger.kernel.org #v3.15
---
-v2: add fixes and comment.
---
drivers/base/node.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
Index: linux-2.6/drivers/base/node.c
===
--- linux-2.6.orig/drivers/base/node.c
+++ linux-2.6/drivers/base/node.c
@@ -390,7 +390,18 @@ int register_mem_sect_under_node(struct
sect_end_pfn = section_nr_to_pfn(mem_blk->end_section_nr);
sect_end_pfn += PAGES_PER_SECTION - 1;
for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
- int page_nid;
+ int page_nid, scn_nr;
+
+ /*
+* memory block could have several absent sections from start.
+* skip pfn range from absent section
+*/
+ scn_nr = pfn_to_section_nr(pfn);
+ if (!present_section_nr(scn_nr)) {
+ pfn = round_down(pfn + PAGES_PER_SECTION,
+PAGES_PER_SECTION) - 1;
+ continue;
+ }
page_nid = get_nid_for_pfn(pfn);
if (page_nid < 0)
@@ -426,10 +437,22 @@ int unregister_mem_sect_under_nodes(stru
return -ENOMEM;
nodes_clear(*unlinked_nodes);
- sect_start_pfn = section_nr_to_pfn(phys_index);
- sect_end_pfn = sect_start_pfn + PAGES_PER_SECTION - 1;
+ sect_start_pfn = section_nr_to_pfn(mem_blk->start_section_nr);
+ sect_end_pfn = section_nr_to_pfn(mem_blk->end_section_nr);
+ sect_end_pfn += PAGES_PER_SECTION - 1;
for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
- int nid;
+ int nid, scn_nr;
+
+ /*
+* memory block could have several absent sections from start.
+* skip pfn range from absent section
+*/
+ scn_nr = pfn_to_section_nr(pfn);
+ if (!present_section_nr(scn_nr)) {
+ pfn = round_down(pfn + PAGES_PER_SECTION,
+PAGES_PER_SECTION) - 1;
+ continue;
+ }
nid = get_nid_for_pfn(pfn);
if (nid < 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 V3 2/3] kvm: don't register wildcard MMIO EVENTFD on two buses
On 08/25/2015 07:51 PM, Michael S. Tsirkin wrote:
> On Tue, Aug 25, 2015 at 05:05:47PM +0800, Jason Wang wrote:
>> > We register wildcard mmio eventfd on two buses, one for KVM_MMIO_BUS
>> > and another is KVM_FAST_MMIO_BUS. This leads to issue:
>> >
>> > - kvm_io_bus_destroy() knows nothing about the devices on two buses
>> > points to a single dev. Which will lead double free [1] during exit.
>> > - wildcard eventfd ignores data len, so it was registered as a
>> > kvm_io_range with zero length. This will fail the binary search in
>> > kvm_io_bus_get_first_dev() when we try to emulate through
>> > KVM_MMIO_BUS. This will cause userspace io emulation request instead
>> > of a eventfd notification (virtqueue kick will be trapped by qemu
>> > instead of vhost in this case).
>> >
>> > Fixing this by don't register wildcard mmio eventfd on two
>> > buses. Instead, only register it in KVM_FAST_MMIO_BUS. This fixes the
>> > double free issue of kvm_io_bus_destroy(). For the arch/setups that
>> > does not utilize KVM_FAST_MMIO_BUS, before searching KVM_MMIO_BUS, try
>> > KVM_FAST_MMIO_BUS first to see it it has a match.
>> >
>> > [1] Panic caused by double free:
>> >
>> > CPU: 1 PID: 2894 Comm: qemu-system-x86 Not tainted 3.19.0-26-generic
>> > #28-Ubuntu
>> > Hardware name: LENOVO 2356BG6/2356BG6, BIOS G7ET96WW (2.56 ) 09/12/2013
>> > task: 88009ae0c4b0 ti: 88020e7f task.ti: 88020e7f
>> > RIP: 0010:[] []
>> > ioeventfd_release+0x28/0x60 [kvm]
>> > RSP: 0018:88020e7f3bc8 EFLAGS: 00010292
>> > RAX: dead00200200 RBX: 8801ec19c900 RCX: 00018200016d
>> > RDX: 8801ec19cf80 RSI: ea0008bf1d40 RDI: 8801ec19c900
>> > RBP: 88020e7f3bd8 R08: 2fc75a01 R09: 00018200016d
>> > R10: c07df6ae R11: 88022fc75a98 R12: 88021e7cc000
>> > R13: 88021e7cca48 R14: 88021e7cca50 R15: 8801ec19c880
>> > FS: 7fc1ee3e6700() GS:88023e24()
>> > knlGS:
>> > CS: 0010 DS: ES: CR0: 80050033
>> > CR2: 7f8f389d8000 CR3: 00023dc13000 CR4: 001427e0
>> > Stack:
>> > 88021e7cc000 88020e7f3be8 c07e2622
>> > 88020e7f3c38 c07df69a 880232524160 88020e792d80
>> > 880219b78c00 0008 8802321686a8
>> > Call Trace:
>> > [] ioeventfd_destructor+0x12/0x20 [kvm]
>> > [] kvm_put_kvm+0xca/0x210 [kvm]
>> > [] kvm_vcpu_release+0x18/0x20 [kvm]
>> > [] __fput+0xe7/0x250
>> > [] fput+0xe/0x10
>> > [] task_work_run+0xd4/0xf0
>> > [] do_exit+0x368/0xa50
>> > [] ? recalc_sigpending+0x1f/0x60
>> > [] do_group_exit+0x45/0xb0
>> > [] get_signal+0x291/0x750
>> > [] do_signal+0x28/0xab0
>> > [] ? do_futex+0xdb/0x5d0
>> > [] ? __wake_up_locked_key+0x18/0x20
>> > [] ? SyS_futex+0x76/0x170
>> > [] do_notify_resume+0x69/0xb0
>> > [] int_signal+0x12/0x17
>> > Code: 5d c3 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 8b 7f
>> > 20 e8 06 d6 a5 c0 48 8b 43 08 48 8b 13 48 89 df 48 89 42 08 <48> 89 10 48
>> > b8 00 01 10 00 00
>> > RIP [] ioeventfd_release+0x28/0x60 [kvm]
>> > RSP
>> >
>> > Cc: Gleb Natapov
>> > Cc: Paolo Bonzini
>> > Cc: Michael S. Tsirkin
>> > Signed-off-by: Jason Wang
>> > ---
>> > Changes from V2:
>> > - Tweak styles and comment suggested by Cornelia.
>> > Changes from v1:
>> > - change ioeventfd_bus_from_flags() to return KVM_FAST_MMIO_BUS when
>> > needed to save lots of unnecessary changes.
>> > ---
>> > virt/kvm/eventfd.c | 31 +--
>> > virt/kvm/kvm_main.c | 16 ++--
>> > 2 files changed, 23 insertions(+), 24 deletions(-)
>> >
>> > diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
>> > index 9ff4193..c3ffdc3 100644
>> > --- a/virt/kvm/eventfd.c
>> > +++ b/virt/kvm/eventfd.c
>> > @@ -762,13 +762,16 @@ ioeventfd_check_collision(struct kvm *kvm, struct
>> > _ioeventfd *p)
>> >return false;
>> > }
>> >
>> > -static enum kvm_bus ioeventfd_bus_from_flags(__u32 flags)
>> > +static enum kvm_bus ioeventfd_bus_from_args(struct kvm_ioeventfd *args)
>> > {
>> > - if (flags & KVM_IOEVENTFD_FLAG_PIO)
>> > + if (args->flags & KVM_IOEVENTFD_FLAG_PIO)
>> >return KVM_PIO_BUS;
>> > - if (flags & KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY)
>> > + if (args->flags & KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY)
>> >return KVM_VIRTIO_CCW_NOTIFY_BUS;
>> > - return KVM_MMIO_BUS;
>> > + /* When length is ignored, MMIO is put on a separate bus, for
>> > + * faster lookups.
>> > + */
>> > + return args->len ? KVM_MMIO_BUS : KVM_FAST_MMIO_BUS;
>> > }
>> >
>> > static int
>> > @@ -779,7 +782,7 @@ kvm_assign_ioeventfd(struct kvm *kvm, struct
>> > kvm_ioeventfd *args)
>> >struct eventfd_ctx *eventfd;
>> >int ret;
>> >
>> > - bus_idx = ioeventfd_bus_from_flags(args->flags);
>> > + bus_idx = ioeventfd_bus_from_args(args);
>> >/* must be natural-word sized, or 0 to ignore length */
Re: [PATCH V2 3/3] kvm: add tracepoint for fast mmio
On 08/25/2015 07:34 PM, Michael S. Tsirkin wrote:
> On Tue, Aug 25, 2015 at 03:47:15PM +0800, Jason Wang wrote:
>> > Cc: Gleb Natapov
>> > Cc: Paolo Bonzini
>> > Cc: Michael S. Tsirkin
>> > Signed-off-by: Jason Wang
>> > ---
>> > arch/x86/kvm/trace.h | 17 +
>> > arch/x86/kvm/vmx.c | 1 +
>> > arch/x86/kvm/x86.c | 1 +
>> > 3 files changed, 19 insertions(+)
>> >
>> > diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
>> > index 4eae7c3..2d4e81a 100644
>> > --- a/arch/x86/kvm/trace.h
>> > +++ b/arch/x86/kvm/trace.h
>> > @@ -128,6 +128,23 @@ TRACE_EVENT(kvm_pio,
>> > __entry->count > 1 ? "(...)" : "")
>> > );
>> >
>> > +TRACE_EVENT(kvm_fast_mmio,
>> > + TP_PROTO(u64 gpa),
>> > + TP_ARGS(gpa),
>> > +
>> > + TP_STRUCT__entry(
>> > + __field(u64,gpa)
>> > + ),
>> > +
>> > + TP_fast_assign(
>> > + __entry->gpa= gpa;
>> > + ),
>> > +
>> > + TP_printk("fast mmio at gpa 0x%llx", __entry->gpa)
>> > +);
>> > +
>> > +
>> > +
> don't add multiple empty lines please.
>
Ok
--
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 V2 2/3] kvm: don't register wildcard MMIO EVENTFD on two buses
On 08/25/2015 07:33 PM, Michael S. Tsirkin wrote: > On Tue, Aug 25, 2015 at 03:47:14PM +0800, Jason Wang wrote: >> > We register wildcard mmio eventfd on two buses, one for KVM_MMIO_BUS >> > and another is KVM_FAST_MMIO_BUS. This leads to issue: >> > >> > - kvm_io_bus_destroy() knows nothing about the devices on two buses >> > points to a single dev. Which will lead double free [1] during exit. >> > - wildcard eventfd ignores data len, so it was registered as a >> > kvm_io_range with zero length. This will fail the binary search in >> > kvm_io_bus_get_first_dev() when we try to emulate through >> > KVM_MMIO_BUS. This will cause userspace io emulation request instead >> > of a eventfd notification (virtqueue kick will be trapped by qemu >> > instead of vhost in this case). >> > >> > Fixing this by don't register wildcard mmio eventfd on two >> > buses. Instead, only register it in KVM_FAST_MMIO_BUS. This fixes the >> > double free issue of kvm_io_bus_destroy(). For the arch/setups that >> > does not utilize KVM_FAST_MMIO_BUS, before searching KVM_MMIO_BUS, try >> > KVM_FAST_MMIO_BUS first to see it it has a match. >> > >> > [1] Panic caused by double free: >> > >> > CPU: 1 PID: 2894 Comm: qemu-system-x86 Not tainted 3.19.0-26-generic >> > #28-Ubuntu >> > Hardware name: LENOVO 2356BG6/2356BG6, BIOS G7ET96WW (2.56 ) 09/12/2013 >> > task: 88009ae0c4b0 ti: 88020e7f task.ti: 88020e7f >> > RIP: 0010:[] [] >> > ioeventfd_release+0x28/0x60 [kvm] >> > RSP: 0018:88020e7f3bc8 EFLAGS: 00010292 >> > RAX: dead00200200 RBX: 8801ec19c900 RCX: 00018200016d >> > RDX: 8801ec19cf80 RSI: ea0008bf1d40 RDI: 8801ec19c900 >> > RBP: 88020e7f3bd8 R08: 2fc75a01 R09: 00018200016d >> > R10: c07df6ae R11: 88022fc75a98 R12: 88021e7cc000 >> > R13: 88021e7cca48 R14: 88021e7cca50 R15: 8801ec19c880 >> > FS: 7fc1ee3e6700() GS:88023e24() >> > knlGS: >> > CS: 0010 DS: ES: CR0: 80050033 >> > CR2: 7f8f389d8000 CR3: 00023dc13000 CR4: 001427e0 >> > Stack: >> > 88021e7cc000 88020e7f3be8 c07e2622 >> > 88020e7f3c38 c07df69a 880232524160 88020e792d80 >> > 880219b78c00 0008 8802321686a8 >> > Call Trace: >> > [] ioeventfd_destructor+0x12/0x20 [kvm] >> > [] kvm_put_kvm+0xca/0x210 [kvm] >> > [] kvm_vcpu_release+0x18/0x20 [kvm] >> > [] __fput+0xe7/0x250 >> > [] fput+0xe/0x10 >> > [] task_work_run+0xd4/0xf0 >> > [] do_exit+0x368/0xa50 >> > [] ? recalc_sigpending+0x1f/0x60 >> > [] do_group_exit+0x45/0xb0 >> > [] get_signal+0x291/0x750 >> > [] do_signal+0x28/0xab0 >> > [] ? do_futex+0xdb/0x5d0 >> > [] ? __wake_up_locked_key+0x18/0x20 >> > [] ? SyS_futex+0x76/0x170 >> > [] do_notify_resume+0x69/0xb0 >> > [] int_signal+0x12/0x17 >> > Code: 5d c3 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 8b 7f >> > 20 e8 06 d6 a5 c0 48 8b 43 08 48 8b 13 48 89 df 48 89 42 08 <48> 89 10 48 >> > b8 00 01 10 00 00 >> > RIP [] ioeventfd_release+0x28/0x60 [kvm] >> > RSP >> > >> > Cc: Gleb Natapov >> > Cc: Paolo Bonzini >> > Cc: Michael S. Tsirkin >> > Signed-off-by: Jason Wang > I'm worried that this slows down the regular MMIO. I doubt whether or not it was measurable. > Could you share performance #s please? > You need a mix of len=0 and len=2 matches. Ok. > One solution for the first issue is to create two ioeventfd objects instead. Sounds good. > For the second issue, we could change bsearch compare function instead. What do you mean by "second issue" ? > Again, affects all devices to performance #s would be needed. > -- 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 RESEND] irqchip, gicv3-its, numa: Workaround for Cavium ThunderX erratum 23144
This implements a workaround for gicv3-its erratum 23144 on Cavium's
ThunderX dual-socket platforms, where LPI cannot be routed to a
redistributors present on a foreign node.
Signed-off-by: Ganapatrao Kulkarni
Signed-off-by: Robert Richter
---
The patch below is on top of Robert's recent gicv3 errata patch
submission v4 and my arm64 numa patches v5.
v2:
updatated as per Marc Zyngier's review comments.
drivers/irqchip/irq-gic-v3-its.c | 49 ++--
1 file changed, 42 insertions(+), 7 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index b83b132..47fded0 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -39,7 +39,8 @@
#include "irqchip.h"
#define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0)
-#define ITS_FLAGS_CAVIUM_THUNDERX (1ULL << 1)
+#define ITS_WORKAROUND_CAVIUM_22375(1ULL << 1)
+#define ITS_WORKAROUND_CAVIUM_23144(1ULL << 2)
#define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
@@ -72,6 +73,7 @@ struct its_node {
struct list_headits_device_list;
u64 flags;
u32 ite_size;
+ int numa_node;
};
#define ITS_ITT_ALIGN SZ_256
@@ -606,11 +608,20 @@ static void its_eoi_irq(struct irq_data *d)
static int its_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
bool force)
{
- unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
+ unsigned int cpu;
+ const struct cpumask *cpu_mask = cpu_online_mask;
struct its_device *its_dev = irq_data_get_irq_chip_data(d);
struct its_collection *target_col;
u32 id = its_get_event_id(d);
+ /* lpi cannot be routed to a redistributor that is on a foreign node */
+ if (its_dev->its->flags & ITS_WORKAROUND_CAVIUM_23144) {
+ cpu_mask = cpumask_of_node(its_dev->its->numa_node);
+ if (!cpumask_intersects(mask_val, cpu_mask))
+ return -EINVAL;
+ }
+
+ cpu = cpumask_any_and(mask_val, cpu_mask);
if (cpu >= nr_cpu_ids)
return -EINVAL;
@@ -842,7 +853,7 @@ static int its_alloc_tables(struct its_node *its)
u64 typer;
u32 ids;
- if (its->flags & ITS_FLAGS_CAVIUM_THUNDERX) {
+ if (its->flags & ITS_WORKAROUND_CAVIUM_22375) {
/*
* erratum 22375: only alloc 8MB table size
* erratum 24313: ignore memory access type
@@ -1349,9 +1360,14 @@ static void its_irq_domain_activate(struct irq_domain
*domain,
{
struct its_device *its_dev = irq_data_get_irq_chip_data(d);
u32 event = its_get_event_id(d);
+ const struct cpumask *cpu_mask = cpu_online_mask;
+
+ /* get the cpu_mask of local node */
+ if (IS_ENABLED(CONFIG_NUMA))
+ cpu_mask = cpumask_of_node(its_dev->its->numa_node);
/* Bind the LPI to the first possible CPU */
- its_dev->event_map.col_map[event] = cpumask_first(cpu_online_mask);
+ its_dev->event_map.col_map[event] = cpumask_first(cpu_mask);
/* Map the GIC IRQ and event to the device */
its_send_mapvi(its_dev, d->hwirq, event);
@@ -1434,11 +1450,19 @@ static int its_force_quiescent(void __iomem *base)
}
}
-static void its_enable_cavium_thunderx(void *data)
+static void its_enable_cavium_thunderx_22375(void *data)
{
struct its_node *its = data;
- its->flags |= ITS_FLAGS_CAVIUM_THUNDERX;
+ its->flags |= ITS_WORKAROUND_CAVIUM_22375;
+}
+
+static void its_enable_cavium_thunderx_23144(void *data)
+{
+ struct its_node *its = data;
+
+ if (num_possible_nodes() > 1)
+ its->flags |= ITS_WORKAROUND_CAVIUM_23144;
}
static const struct gic_capabilities its_errata[] = {
@@ -1446,7 +1470,13 @@ static const struct gic_capabilities its_errata[] = {
.desc = "ITS: Cavium errata 22375, 24313",
.iidr = 0xa100034c, /* ThunderX pass 1.x */
.mask = 0x0fff,
- .init = its_enable_cavium_thunderx,
+ .init = its_enable_cavium_thunderx_22375,
+ },
+ {
+ .desc = "ITS: Cavium errata 23144",
+ .iidr = 0xa100034c, /* ThunderX pass 1.x */
+ .mask = 0x0fff,
+ .init = its_enable_cavium_thunderx_23144,
},
{
}
@@ -1465,6 +1495,7 @@ static int its_probe(struct device_node *node, struct
irq_domain *parent)
u32 val;
u64 baser, tmp;
int err;
+ int numa_node;
err = of_address_to_resource(node, 0, &res);
if (err) {
@@ -1472,6 +1503,9 @@ static int its_probe(struct device_node *node, struct
irq_domain *parent)
return -ENXIO;
}
+ /* get numa affinity of its node*
Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting
* Johannes Berg wrote: > On Tue, 2015-08-25 at 12:07 +0200, Ingo Molnar wrote: > > Having a separate syscall has two (big!) appeals: > > > > - we wouldn't have to touch existing system calls at all. > > > > - extended error reporting would be available for any system call that > > opts to > >use it. (The current scheme as submitted is only available to system > > calls > >using the perf-style flexible attribute ABI.) > > Yeah, I agree this is nice. However, more generally, I think we need to > actually think more about the module problem then since while syscalls > can't be implemented in modules (I think) they can still end up calling > into modules. > > Of course a first iteration could be exactly like what Alexander > posted. > > The other issue with this is namespacing - can all syscalls, and > everything that eventually gets called, really use a single error code > namespace with its 3k limit? [...] No, the current MAX_ERRNO is probably not big enough if this scheme is successful, and I don't see any reason why it wouldn't be successful: I think this feature would be the biggest usability feature added to Linux system calls and to Linux system tooling in the last 10 years or so. > [...] On the one hand I'm thinking "3k strings are so big ... we don't want > more", but on the other hand all kinds of drivers etc. might start getting > annotations? We could extend it with some arch work. The per arch work involves making sure there's no valid kernel address at [-MAX_ERRNO...-1]. So I wouldn't worry about it too much, let's agree on a good ABI and let's just start using it, and if we grow out of -4K we can extend things step by step. > > Ok. So assuming we can make a 1:1 mapping between the 'extended error code' > > integer space and the message:owner strings, it would be enough for netlink > > to > > pass along the integer code itself, not the full strings? > > Considering that this would likely have to be opt-in at the netlink level > (e.g. > through a flag in the request message), perhaps. I'd say it'd still be easier > for the message to carry the intended error code (e.g. -EINVAL) and the > actual > message in the ACK message [where requested]. That way, applications that > actually behave depending on the error code can far more easily be extended. Ok. I think we should include the extended error code as well, in case an app wants to pass it to some more generic library. > > That would simplify things and make the scheme more robust from a security > > POV > > I suspect. > > You could also argue the other way around, in that being able to look up > (from > userspace) arbitrary extended error IDs, even those that haven't ever been > used, > could be an information leak of sorts. The fact is that kernel<->tooling error reporting sucks big time here and today, in large part due to errno limitations, and arguing that it's somehow helping security is the Stockholm Syndrome at its best. > > So my hope would be that we can represent this all with a single 'large' > > error > > code integer space. That integer would be constant and translateable (as > > long > > as the module is loaded). > > Ok, I wasn't really what I was assuming. As I said above, on the one > hand I agree, but on the other I'm looking at the reality of a few > hundred (!) -EINVAL callsites in net/wireless/nl80211.c alone, so > having an overall 3k limit seems somewhat low. Agreed - but it's not a hard limit really. > > That way the error passing mechanism wouldn't have to be specifically > > module-aware - during build we generate the integer space, with all > > possible > > modules considered. > > That would be no improvement for me as I work heavily with (upstream) modules > that are compiled out-of-tree, so I'm not all inclined to spend much time on > it > if that ends up being the solution ;) Perhaps, as long as the number allocation is dynamic and non-ABI there's no reason why this couldn't be added later on. Thanks, Ingo -- 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 v5 0/8] Add generic support for relaxed atomics
Hi Will,
On Thu, Aug 06, 2015 at 05:54:36PM +0100, Will Deacon wrote:
>
> Will Deacon (8):
> atomics: add acquire/release/relaxed variants of some atomic
> operations
> asm-generic: rework atomic-long.h to avoid bulk code duplication
> asm-generic: add relaxed/acquire/release variants for atomic_long_t
> lockref: remove homebrew cmpxchg64_relaxed macro definition
> locking/qrwlock: implement queue_write_unlock using smp_store_release
> locking/qrwlock: make use of acquire/release/relaxed atomics
> include/llist: use linux/atomic.h instead of asm/cmpxchg.h
Should we step further to privatize asm/cmpxchg.h entirely? Keep it only
included in arch/*?
Because after your next patch, in some configurations, asm/cmpxchg.h of
ARM only provides the definition of {cmpxchg,xchg}_relaxed, others are
built in linux/atomic.h. Further more, other architecture may implement
asm/cmpxchg.h similarly in the future. So, IIUC, we actually don't
guarantee all cmpxchg(), xchg() and their variants are defined in
asm/cmpxchg.h.
Though current users of asm/cmpxchg.h outside arch/* are fine,
because they all happen to have got linux/atomic.h included. But we'd
better change the current users and call out that asm/cmpxchg.h is
privatized in the document.
> ARM: atomics: define our SMP atomics in terms of _relaxed operations
Consider this patch maybe? I did a simple build test on X86.
Regards,
Boqun
---
Subject: [PATCH] atomics,cmpxchg: Privatize the inclusion of asm/cmpxchg.h
After commit:
atomics: add acquire/release/relaxed variants of some atomic operations
Architectures may only provide {cmp,}xchg_relaxed definitions in
asm/cmpxchg.h. Other variants, such as {cmp,}xchg, may be built in
linux/atomic.h, which means simply including asm/cmpxchg.h may not get
the definitions of all the{cmp,}xchg variants. Therefore, we should
privatize the inclusions of asm/cmpxchg.h to keep it only included in
arch/* and replace the inclusions outside with linux/atomic.h
Signed-off-by: Boqun Feng
---
Documentation/atomic_ops.txt| 4
drivers/net/ethernet/sfc/mcdi.c | 2 +-
drivers/phy/phy-rcar-gen2.c | 3 +--
drivers/staging/speakup/selection.c | 2 +-
4 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
index b19fc34..c9d1cac 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt
@@ -542,6 +542,10 @@ The routines xchg() and cmpxchg() must provide the same
exact
memory-barrier semantics as the atomic and bit operations returning
values.
+Note: If someone wants to use xchg(), cmpxchg() and their variants,
+linux/atomic.h should be included rather than asm/cmpxchg.h, unless
+the code is in arch/* and can take care of itself.
+
Spinlocks and rwlocks have memory barrier expectations as well.
The rule to follow is simple:
diff --git a/drivers/net/ethernet/sfc/mcdi.c b/drivers/net/ethernet/sfc/mcdi.c
index 81640f8..968383e 100644
--- a/drivers/net/ethernet/sfc/mcdi.c
+++ b/drivers/net/ethernet/sfc/mcdi.c
@@ -9,7 +9,7 @@
#include
#include
-#include
+#include
#include "net_driver.h"
#include "nic.h"
#include "io.h"
diff --git a/drivers/phy/phy-rcar-gen2.c b/drivers/phy/phy-rcar-gen2.c
index 39d9b29..117b495 100644
--- a/drivers/phy/phy-rcar-gen2.c
+++ b/drivers/phy/phy-rcar-gen2.c
@@ -17,8 +17,7 @@
#include
#include
#include
-
-#include
+#include
#define USBHS_LPSTS0x02
#define USBHS_UGCTRL 0x80
diff --git a/drivers/staging/speakup/selection.c
b/drivers/staging/speakup/selection.c
index a031570..81c0888 100644
--- a/drivers/staging/speakup/selection.c
+++ b/drivers/staging/speakup/selection.c
@@ -7,7 +7,7 @@
#include
#include
#include
-#include
+#include
#include "speakup.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 10/11] dma: rename dma_*_writecombine() to dma_*_wc()
* Andrew Morton wrote: > > There's a catch-22 issue here either way, for instance this rename patch > > has > > been being baked for probably 2 releases already but the difficulty has > > been > > trying to find the appropriate time to merge it without conflict. > > > > If you do it in the beginning of the merge window, you have to ask yourself > > in > > what tree it will be done. Since subsystems are topic specific that means > > that > > subsystem will end up having a conflict at the end of the merge window. > > Yes it's a special case. I think the best way of handling such things is to > get > them in to Linus either right at the end of the merge window or the day after > he > releases -rc1. This is when most people's trees are mostly empty. Yes, that was the plan last time around as well - but the end of the merge window is when we have the least maintainer bandwidth as well ... Anyway, I applied most of the patches (sans the rename), so the rename patch should be a lot simpler to execute at the right moment this time around. Thanks, Ingo -- 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] Use 2GB memory block size on large-memory x86-64 systems
* Yinghai Lu wrote:
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -390,8 +390,14 @@ int register_mem_sect_under_node(struct memory_block
> *mem_blk, int nid)
> sect_end_pfn = section_nr_to_pfn(mem_blk->end_section_nr);
> sect_end_pfn += PAGES_PER_SECTION - 1;
> for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
> - int page_nid;
> + int page_nid, scn_nr;
>
> + scn_nr = pfn_to_section_nr(pfn);
> + if (!present_section_nr(scn_nr)) {
> + pfn = round_down(pfn + PAGES_PER_SECTION,
> + PAGES_PER_SECTION) - 1;
> + continue;
> + }
> page_nid = get_nid_for_pfn(pfn);
> if (page_nid < 0)
> continue;
> @@ -426,10 +432,18 @@ int unregister_mem_sect_under_nodes(struct memory_block
> *mem_blk,
> return -ENOMEM;
> nodes_clear(*unlinked_nodes);
>
> - sect_start_pfn = section_nr_to_pfn(phys_index);
> - sect_end_pfn = sect_start_pfn + PAGES_PER_SECTION - 1;
> + sect_start_pfn = section_nr_to_pfn(mem_blk->start_section_nr);
> + sect_end_pfn = section_nr_to_pfn(mem_blk->end_section_nr);
> + sect_end_pfn += PAGES_PER_SECTION - 1;
> for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
> - int nid;
> + int nid, scn_nr;
> +
> + scn_nr = pfn_to_section_nr(pfn);
> + if (!present_section_nr(scn_nr)) {
> + pfn = round_down(pfn + PAGES_PER_SECTION,
> + PAGES_PER_SECTION) - 1;
> + continue;
> + }
NAK due to lack of cleanliness: the two loops look almost identical - this sure
can be factored out...
Thanks,
Ingo
--
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] mpt3sas: Refcount sas_device objects and fix unsafe list usage
From: Nicholas Bellinger
These objects can be referenced concurrently throughout the driver, we
need a way to make sure threads can't delete them out from under
each other. This patch adds the refcount, and refactors the code to use
it.
Additionally, we cannot iterate over the sas_device_list without
holding the lock, or we risk corrupting random memory if items are
added or deleted as we iterate. This patch refactors _scsih_probe_sas()
to use the sas_device_list in a safe way.
This patch is a port of Calvin's PATCH-v4 for mpt2sas code.
Cc: Calvin Owens
Cc: Christoph Hellwig
Cc: Sreekanth Reddy
Cc: MPT-FusionLinux.pdl
Signed-off-by: Nicholas Bellinger
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 23 +-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 476 +--
drivers/scsi/mpt3sas/mpt3sas_transport.c | 12 +-
3 files changed, 355 insertions(+), 156 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index afa8816..fe29ac0 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -209,6 +209,7 @@ struct Mpi2ManufacturingPage11_t {
* @flags: MPT_TARGET_FLAGS_XXX flags
* @deleted: target flaged for deletion
* @tm_busy: target is busy with TM request.
+ * @sdev: The sas_device associated with this target
*/
struct MPT3SAS_TARGET {
struct scsi_target *starget;
@@ -218,6 +219,7 @@ struct MPT3SAS_TARGET {
u32 flags;
u8 deleted;
u8 tm_busy;
+ struct _sas_device *sdev;
};
@@ -294,6 +296,7 @@ struct _internal_cmd {
* @responding: used in _scsih_sas_device_mark_responding
* @fast_path: fast path feature enable bit
* @pfa_led_on: flag for PFA LED status
+ * @refcount: reference count for deletion
*
*/
struct _sas_device {
@@ -315,8 +318,24 @@ struct _sas_device {
u8 responding;
u8 fast_path;
u8 pfa_led_on;
+ struct kref refcount;
};
+static inline void sas_device_get(struct _sas_device *s)
+{
+ kref_get(&s->refcount);
+}
+
+static inline void sas_device_free(struct kref *r)
+{
+ kfree(container_of(r, struct _sas_device, refcount));
+}
+
+static inline void sas_device_put(struct _sas_device *s)
+{
+ kref_put(&s->refcount, sas_device_free);
+}
+
/**
* struct _raid_device - raid volume link list
* @list: sas device list
@@ -1043,7 +1062,9 @@ struct _sas_node *mpt3sas_scsih_expander_find_by_handle(
struct MPT3SAS_ADAPTER *ioc, u16 handle);
struct _sas_node *mpt3sas_scsih_expander_find_by_sas_address(
struct MPT3SAS_ADAPTER *ioc, u64 sas_address);
-struct _sas_device *mpt3sas_scsih_sas_device_find_by_sas_address(
+struct _sas_device *mpt3sas_get_sdev_by_addr(
+struct MPT3SAS_ADAPTER *ioc, u64 sas_address);
+struct _sas_device *__mpt3sas_get_sdev_by_addr(
struct MPT3SAS_ADAPTER *ioc, u64 sas_address);
void mpt3sas_port_enable_complete(struct MPT3SAS_ADAPTER *ioc);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 5a97e32..7142e3b 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -518,8 +518,61 @@ _scsih_determine_boot_device(struct MPT3SAS_ADAPTER *ioc,
}
}
+static struct _sas_device *
+__mpt3sas_get_sdev_from_target(struct MPT3SAS_ADAPTER *ioc,
+ struct MPT3SAS_TARGET *tgt_priv)
+{
+ struct _sas_device *ret;
+
+ assert_spin_locked(&ioc->sas_device_lock);
+
+ ret = tgt_priv->sdev;
+ if (ret)
+ sas_device_get(ret);
+
+ return ret;
+}
+
+static struct _sas_device *
+mpt3sas_get_sdev_from_target(struct MPT3SAS_ADAPTER *ioc,
+ struct MPT3SAS_TARGET *tgt_priv)
+{
+ struct _sas_device *ret;
+ unsigned long flags;
+
+ spin_lock_irqsave(&ioc->sas_device_lock, flags);
+ ret = __mpt3sas_get_sdev_from_target(ioc, tgt_priv);
+ spin_unlock_irqrestore(&ioc->sas_device_lock, flags);
+
+ return ret;
+}
+
+struct _sas_device *
+__mpt3sas_get_sdev_by_addr(struct MPT3SAS_ADAPTER *ioc,
+ u64 sas_address)
+{
+ struct _sas_device *sas_device;
+
+ assert_spin_locked(&ioc->sas_device_lock);
+
+ list_for_each_entry(sas_device, &ioc->sas_device_list, list)
+ if (sas_device->sas_address == sas_address)
+ goto found_device;
+
+ list_for_each_entry(sas_device, &ioc->sas_device_init_list, list)
+ if (sas_device->sas_address == sas_address)
+ goto found_device;
+
+ return NULL;
+
+found_device:
+ sas_device_get(sas_device);
+ return sas_device;
+}
+
+
/**
- * mpt3sas_scsih_sas_device_find_by_sas_address - sas device search
+ * mpt3sas_get_sdev_by_addr - sas device search
* @ioc: per adapter object
* @sas_address: sas address
* Context: Calling function should acquire ioc->sas_device_lock
@@ -528,24 +581,44 @@ _scsih_determine_boot_device(
[PATCH 2/2] mpt3sas: Refcount fw_events and fix unsafe list usage
From: Nicholas Bellinger
The fw_event_work struct is concurrently referenced at shutdown, so
add a refcount to protect it, and refactor the code to use it.
Additionally, refactor _scsih_fw_event_cleanup_queue() such that it
no longer iterates over the list without holding the lock, since
_firmware_event_work() concurrently deletes items from the list.
This patch is a port of Calvin's PATCH-v4 for mpt2sas code.
Cc: Calvin Owens
Cc: Christoph Hellwig
Cc: Sreekanth Reddy
Cc: MPT-FusionLinux.pdl
Signed-off-by: Nicholas Bellinger
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 116 ---
1 file changed, 94 insertions(+), 22 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 7142e3b..4cb7e89 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -175,6 +175,7 @@ struct sense_info {
* @VP_ID: virtual port id
* @ignore: flag meaning this event has been marked to ignore
* @event: firmware event MPI2_EVENT_XXX defined in mpt2_ioc.h
+ * @refcount: reference count for fw_event_work
* @event_data: reply event data payload follows
*
* This object stored on ioc->fw_event_list.
@@ -191,9 +192,37 @@ struct fw_event_work {
u8 VP_ID;
u8 ignore;
u16 event;
+ struct kref refcount;
charevent_data[0] __aligned(4);
};
+static void fw_event_work_free(struct kref *r)
+{
+ kfree(container_of(r, struct fw_event_work, refcount));
+}
+
+static void fw_event_work_get(struct fw_event_work *fw_work)
+{
+ kref_get(&fw_work->refcount);
+}
+
+static void fw_event_work_put(struct fw_event_work *fw_work)
+{
+ kref_put(&fw_work->refcount, fw_event_work_free);
+}
+
+static struct fw_event_work *alloc_fw_event_work(int len)
+{
+ struct fw_event_work *fw_event;
+
+ fw_event = kzalloc(sizeof(*fw_event) + len, GFP_ATOMIC);
+ if (!fw_event)
+ return NULL;
+
+ kref_init(&fw_event->refcount);
+ return fw_event;
+}
+
/* raid transport support */
static struct raid_template *mpt3sas_raid_template;
@@ -2542,32 +2571,36 @@ _scsih_fw_event_add(struct MPT3SAS_ADAPTER *ioc, struct
fw_event_work *fw_event)
return;
spin_lock_irqsave(&ioc->fw_event_lock, flags);
+ fw_event_work_get(fw_event);
INIT_LIST_HEAD(&fw_event->list);
list_add_tail(&fw_event->list, &ioc->fw_event_list);
INIT_WORK(&fw_event->work, _firmware_event_work);
+ fw_event_work_get(fw_event);
queue_work(ioc->firmware_event_thread, &fw_event->work);
spin_unlock_irqrestore(&ioc->fw_event_lock, flags);
}
/**
- * _scsih_fw_event_free - delete fw_event
+ * _scsih_fw_event_del_from_list - delete fw_event from the list
* @ioc: per adapter object
* @fw_event: object describing the event
* Context: This function will acquire ioc->fw_event_lock.
*
- * This removes firmware event object from link list, frees associated memory.
+ * If the fw_event is on the fw_event_list, remove it and do a put.
*
* Return nothing.
*/
static void
-_scsih_fw_event_free(struct MPT3SAS_ADAPTER *ioc, struct fw_event_work
+_scsih_fw_event_del_from_list(struct MPT3SAS_ADAPTER *ioc, struct fw_event_work
*fw_event)
{
unsigned long flags;
spin_lock_irqsave(&ioc->fw_event_lock, flags);
- list_del(&fw_event->list);
- kfree(fw_event);
+ if (!list_empty(&fw_event->list)) {
+ list_del_init(&fw_event->list);
+ fw_event_work_put(fw_event);
+ }
spin_unlock_irqrestore(&ioc->fw_event_lock, flags);
}
@@ -2587,14 +2620,14 @@ mpt3sas_send_trigger_data_event(struct MPT3SAS_ADAPTER
*ioc,
if (ioc->is_driver_loading)
return;
- fw_event = kzalloc(sizeof(*fw_event) + sizeof(*event_data),
- GFP_ATOMIC);
+ fw_event = alloc_fw_event_work(sizeof(*event_data));
if (!fw_event)
return;
fw_event->event = MPT3SAS_PROCESS_TRIGGER_DIAG;
fw_event->ioc = ioc;
memcpy(fw_event->event_data, event_data, sizeof(*event_data));
_scsih_fw_event_add(ioc, fw_event);
+ fw_event_work_put(fw_event);
}
/**
@@ -2610,12 +2643,13 @@ _scsih_error_recovery_delete_devices(struct
MPT3SAS_ADAPTER *ioc)
if (ioc->is_driver_loading)
return;
- fw_event = kzalloc(sizeof(struct fw_event_work), GFP_ATOMIC);
+ fw_event = alloc_fw_event_work(0);
if (!fw_event)
return;
fw_event->event = MPT3SAS_REMOVE_UNRESPONDING_DEVICES;
fw_event->ioc = ioc;
_scsih_fw_event_add(ioc, fw_event);
+ fw_event_work_put(fw_event);
}
/**
@@ -2629,12 +2663,29 @@ mpt3sas_port_enable_complete(struct MPT3SAS_ADAPTER
*ioc)
{
struct fw_event_work *fw_event;
-
[PATCH 0/2] mpt3sas: Reference counting fixes from in-flight mpt2sas
From: Nicholas Bellinger Hi James & Co, This series is a mpt3sas forward port of Calvin Owens' in-flight reference counting bugfixes for mpt2sas LLD code here: [PATCH v4 0/2] Fixes for memory corruption in mpt2sas http://marc.info/?l=linux-scsi&m=143951695904115&w=2 The differences between mpt2sas + mpt3sas in this area are very, very small, and is required to address a NULL pointer dereference OOPsen in _scsih_probe_sas() -> mpt3sas_transport_port_add() -> sas_port_add_phy() that I've been hitting occasionally on boot during initial LUN scan. So far this code has been tested on v3.14.47 with a small cluster using SAS3008 HBAs plus a few preceeding upstream mpt3sas patches so these patches apply cleanly, and with the changes in place the original OOPsen appears to be resolved. This patch series is cut atop v4.2-rc1 code, and barring any objections from Avago folks et al., should be considered along with Calvin's mpt2sas patch set for v4.3-rc1 code. Thank you, --nab Nicholas Bellinger (2): mpt3sas: Refcount sas_device objects and fix unsafe list usage mpt3sas: Refcount fw_events and fix unsafe list usage drivers/scsi/mpt3sas/mpt3sas_base.h | 23 +- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 592 ++- drivers/scsi/mpt3sas/mpt3sas_transport.c | 12 +- 3 files changed, 449 insertions(+), 178 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/
Re: [PATCH] kernel: make module.c itself more explicitly non-modular
Paul Gortmaker writes:
> The Kconfig currently controlling compilation of this code is:
>
> menuconfig MODULES
>bool "Enable loadable module support"
>
> ...meaning that it currently is not being built as a module by anyone.
> No surprise here, since modular support being a module would be an
> interesting chicken before the egg problem.
>
> Lets remove the use of module_init in this code so that when reading
> the file, there is less doubt that it is builtin-only.
>
> Since module_init translates to device_initcall in the non-modular
> case, the init ordering remains unchanged with this commit. However
> one could argue that fs_initcall makes more sense for proc stuff,
> and we can change the initcall order later and watch for fallout
> if so desired.
This patch is just weird; is this part of something larger you are
trying to do?
I would argue that module_init() should be the default; it implies
no dependencies on the initialization, and it's a common pattern.
Cheers,
Rusty.
> We can't of course delete the module.h include in this case since it
> is used all through the rest of the file.
>
> Cc: Rusty Russell
> Signed-off-by: Paul Gortmaker
> ---
>
> [I was undecided as to whether we should do this in one step
> or two, i.e. instead just make the change to fs_initcall here
> and now, and so went with the more cautious/granular approach.]
>
> kernel/module.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 8f051a106676..7750bdcb12fc 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3947,7 +3947,7 @@ static int __init proc_modules_init(void)
> proc_create("modules", 0, NULL, &proc_modules_operations);
> return 0;
> }
> -module_init(proc_modules_init);
> +device_initcall(proc_modules_init);
> #endif
>
> /* Given an address, look for it in the module exception tables. */
> --
> 2.5.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/
--
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 v2] memory-barriers: remove smp_mb__after_unlock_lock()
On Tue, 2015-08-25 at 17:27 -0700, Paul E. McKenney wrote: > On Thu, Aug 20, 2015 at 04:56:04PM +0100, Will Deacon wrote: > > On Thu, Aug 20, 2015 at 10:45:05AM +0100, Michael Ellerman wrote: > > > On Tue, 2015-08-18 at 09:37 +0100, Will Deacon wrote: > > > > > > > > Thanks, that sounds great. FWIW, there are multiple ways of implementing > > > > the patch (i.e. whether you strengthen lock or unlock). I had a crack at > > > > something here, but it's not tested: > > > > > > > > http://marc.info/?l=linux-arch&m=143758379023849&w=2 > > > > > > I notice you are not changing PPC_RELEASE_BARRIER, but only the spin > > > unlock > > > code. But from my reading of the docs we need to make sure any > > > UNLOCK+LOCK is a > > > full barrier, not just spin unlock/lock? > > > > > > So don't we need to worry about some of the other locks as well? At least > > > rwlock, and mutex fast path? > > > > Hmm, that's a good question. I notice that you don't do any of the SYNC_IO > > stuff for any locks other than spinlocks but I don't know whether > > smp_mb__after_unlock_lock is similarly limited in scope. > > > > Paul? > > I would expect the various locks to have similar ordering characteristics. > > Or am I missing something subtle here? I don't think so. The docs just talk about ACQUIRE/RELEASE, so I think it needs to apply to all lock types. Or at least the list mentioned in the docs which is: (*) spin locks (*) R/W spin locks (*) mutexes (*) semaphores (*) R/W semaphores (*) RCU cheers -- 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] mm: Check if section present during memory block (un)registering
On Tue, Aug 25, 2015 at 4:08 PM, Andrew Morton
wrote:
> On Tue, 25 Aug 2015 15:41:16 -0700 Yinghai Lu wrote:
>
>> Tony found on his setup, if memory block size 512M will cause crash
>> during booting.
>>
>> BUG: unable to handle kernel paging request at ea007420
>> IP: [] get_nid_for_pfn+0x17/0x40
>> PGD 128ffcb067 PUD 128ffc9067 PMD 0
>> Oops: [#1] SMP
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc8 #1
>> ...
>> Call Trace:
>> [] ? register_mem_sect_under_node+0x66/0xe0
>> [] register_one_node+0x17b/0x240
>> [] ? pci_iommu_alloc+0x6e/0x6e
>> [] topology_init+0x3c/0x95
>> [] do_one_initcall+0xcd/0x1f0
>>
>> The system has non continuous RAM address:
>> BIOS-e820: [mem 0x0013-0x001c] usable
>> BIOS-e820: [mem 0x001d7000-0x001ec7ffefff] usable
>> BIOS-e820: [mem 0x001f-0x002b] usable
>> BIOS-e820: [mem 0x002c1800-0x002d6fffefff] usable
>> BIOS-e820: [mem 0x002e-0x0039] usable
>>
>> So there are start sections in memory block not present.
>> For example:
>> memory block : [0x2c1800, 0x2c2000) 512M
>> first three sections are not present.
>>
>> Current register_mem_sect_under_node() assume first section is present,
>> but memory block section number range [start_section_nr, end_section_nr]
>> would include not present section.
>>
>> For arch that support vmemmap, we don't setup memmap for struct page area
>> within not present sections area.
>>
>> So skip the pfn range that belong to not present section.
>>
>> Als fixes unregister_mem_sect_under_nodes().
>
> It appears this should be backported into -stable kernels, yes? Do you
> know which kernel versions need the fix?
should add following according to Tony's email.
Fixes: bdee237c0343 ("x86: mm: Use 2GB memory block size on large
memory x86-64 systems")
Fixes: 982792c782ef ("x86, mm: probe memory block size for generic x86 64bit")
Cc: sta...@kernel.org #v3.15
>
>> --- a/drivers/base/node.c
>> +++ b/drivers/base/node.c
>> @@ -390,8 +390,14 @@ int register_mem_sect_under_node(struct memory_block
>> *mem_blk, int nid)
>> sect_end_pfn = section_nr_to_pfn(mem_blk->end_section_nr);
>> sect_end_pfn += PAGES_PER_SECTION - 1;
>> for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
>> - int page_nid;
>> + int page_nid, scn_nr;
>>
>> + scn_nr = pfn_to_section_nr(pfn);
>> + if (!present_section_nr(scn_nr)) {
>> + pfn = round_down(pfn + PAGES_PER_SECTION,
>> + PAGES_PER_SECTION) - 1;
>> + continue;
>> + }
>
> Can we please add a comment here telling readers why this is being
> done? What scenario is being detected and how it comes about.
>
Yes, should add
/* skip pfn range from absent memory section */
--
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: linux: sata_nv: adma support
On Tue, Aug 25, 2015 at 6:58 AM, Pali Rohár wrote:
> On Tuesday 25 August 2015 07:20:05 Mark Lord wrote:
>> On 15-08-01 09:45 PM, Robert Hancock wrote:
>> >On Sat, Aug 1, 2015 at 2:09 PM, Pali Rohár wrote:
>> >>On Thursday 25 December 2014 07:22:13 Robert Hancock wrote:
>> >>>On Tue, Dec 23, 2014 at 1:51 PM, Pali Rohár
>> >>>wrote:
>> Hello,
>>
>> I have nvidia nforce4 motherboard with nvidia sata controller:
>> ..
>> >>>It looks like something is trying to issue a command to disable APM
>> >>>power management on the drive, and the command fails (likely because
>> >>>it doesn't support that command).
>> ..
>> >> /sbin/hdparm -B254 $DRIVE
>> >>
>> >>And that -B254 cause above error message in dmesg log. Output from
>> >>hdparm is:
>> >>
>> >> /dev/sda:
>> >> setting Advanced Power Management level to 0xfe (254)
>> >> APM_level = not supported
>> ..
>> >> $ sudo hdparm -I /dev/sda | grep -i power
>> >> *Power Management feature set
>>
>> That's not the same as APM ("Advanced" Power Management).
>>
>> >However, these NVIDIA SATAs are black boxes, and rather buggy ones at that,
>> >so it's possible there's an unknown issue there.
>>
>> I wonder if NVIDIA simply bought out the IP from Pacific Digital
>> when they went bust? Pacific Digital invented the original "ADMA",
>> and the pdc_adma.c driver in the kernel knows all about it.
>> If the IP is pretty similar (identical?) then we could probably
>> improve things.
>>
>
> Can you check if nvidia ADMA code and that Pacific Digital ADMA code is
> similar or not?
The ADMA spec that Pacific Digital adapter (somewhat) implements was
documented in a standard, T13 1510D, ATA/ATAPI Host Adapters Standard.
My guess is that is where NVIDIA got the ideas for this controller
setup. I would be fairly surprised if the controller actually
contained any Pacific Digital IP, as the NVIDIA controllers are quite
different (the original ADMA spec didn't envision SATA, NCQ or 64-bit
DMA while the NVIDIA controllers support these for example).
Even if there is some shared IP, the issues with these controllers
seem to be more controller bugs than issues with how the controller is
being used. In fact, the later NVIDIA Windows drivers suspiciously
removed all references to NCQ support in the control panel, which
suggests that maybe even they gave up on it. Even if you don't use any
ADMA features at all (even when using the default Microsoft IDE driver
in Windows), the error handling is very shaky - things like disc read
errors on an optical drive connected to the controller will sometimes
hard-lock the machine.
--
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] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*
Currently apart from dra7, omap5 and amx3 all the other SoCs
are identified using cpu_is_* functions which is not right since
they are all SoCs(System on Chips). Hence changing the SoC
identification code to use soc_is instead of cpu_is and keeping
defines for cpu_is where needed. This allows us to replace the
rest of cpu_is usage along with other fixes as needed.
Acked-by: Russell King
Signed-off-by: Keerthy
---
Changes in v2:
* Corrected a typo in the commit log.
arch/arm/mach-omap2/id.c | 30 +++
arch/arm/mach-omap2/soc.h | 193 ++
2 files changed, 123 insertions(+), 100 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index e3f713f..24f24d4 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -57,15 +57,15 @@ int omap_type(void)
if (val < OMAP2_DEVICETYPE_MASK)
return val;
- if (cpu_is_omap24xx()) {
+ if (soc_is_omap24xx()) {
val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
- } else if (cpu_is_ti81xx()) {
+ } else if (soc_is_ti81xx()) {
val = omap_ctrl_readl(TI81XX_CONTROL_STATUS);
} else if (soc_is_am33xx() || soc_is_am43xx()) {
val = omap_ctrl_readl(AM33XX_CONTROL_STATUS);
- } else if (cpu_is_omap34xx()) {
+ } else if (soc_is_omap34xx()) {
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
- } else if (cpu_is_omap44xx()) {
+ } else if (soc_is_omap44xx()) {
val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
@@ -122,7 +122,7 @@ static u16 tap_prod_id;
void omap_get_die_id(struct omap_die_id *odi)
{
- if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
+ if (soc_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
odi->id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
odi->id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
odi->id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
@@ -218,17 +218,17 @@ static void __init omap3_cpuinfo(void)
* on available features. Upon detection, update the CPU id
* and CPU class bits.
*/
- if (cpu_is_omap3630()) {
+ if (soc_is_omap3630()) {
cpu_name = "OMAP3630";
} else if (soc_is_am35xx()) {
cpu_name = (omap3_has_sgx()) ? "AM3517" : "AM3505";
- } else if (cpu_is_ti816x()) {
+ } else if (soc_is_ti816x()) {
cpu_name = "TI816X";
} else if (soc_is_am335x()) {
cpu_name = "AM335X";
} else if (soc_is_am437x()) {
cpu_name = "AM437x";
- } else if (cpu_is_ti814x()) {
+ } else if (soc_is_ti814x()) {
cpu_name = "TI814X";
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
@@ -275,11 +275,11 @@ void __init omap3xxx_check_features(void)
OMAP3_CHECK_FEATURE(status, SGX);
OMAP3_CHECK_FEATURE(status, NEON);
OMAP3_CHECK_FEATURE(status, ISP);
- if (cpu_is_omap3630())
+ if (soc_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK;
- if (cpu_is_omap3430() || cpu_is_omap3630())
+ if (soc_is_omap3430() || soc_is_omap3630())
omap_features |= OMAP3_HAS_IO_WAKEUP;
- if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
+ if (soc_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
omap_rev() == OMAP3430_REV_ES3_1_2)
omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;
@@ -697,7 +697,7 @@ void __init omap2_set_globals_tap(u32 class, void __iomem
*tap)
tap_base = tap;
/* XXX What is this intended to do? */
- if (cpu_is_omap34xx())
+ if (soc_is_omap34xx())
tap_prod_id = 0x0210;
else
tap_prod_id = 0x0208;
@@ -715,11 +715,11 @@ static const char * const omap_types[] = {
static const char * __init omap_get_family(void)
{
- if (cpu_is_omap24xx())
+ if (soc_is_omap24xx())
return kasprintf(GFP_KERNEL, "OMAP2");
- else if (cpu_is_omap34xx())
+ else if (soc_is_omap34xx())
return kasprintf(GFP_KERNEL, "OMAP3");
- else if (cpu_is_omap44xx())
+ else if (soc_is_omap44xx())
return kasprintf(GFP_KERNEL, "OMAP4");
else if (soc_is_omap54xx())
return kasprintf(GFP_KERNEL, "OMAP5");
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index f97654d..bb824ae 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -148,13 +148,13 @@ static inline int soc_is_omap(void)
/*
* Macros to group OMAP into cpu classes.
* These can be used in most places.
- * cpu_is_omap24xx(): True for OMAP2
[PATCH 6/8] fix staging:android style issue:Comparison to NULL could be written
Signed-off-by: Peng Sun
---
drivers/staging/android/sw_sync.c | 6 +++---
drivers/staging/android/sync.c| 18 +-
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/android/sw_sync.c
b/drivers/staging/android/sw_sync.c
index c90838d..29b5c35 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -145,7 +145,7 @@ static int sw_sync_open(struct inode *inode, struct file
*file)
get_task_comm(task_comm, current);
obj = sw_sync_timeline_create(task_comm);
- if (obj == NULL)
+ if (!obj)
return -ENOMEM;
file->private_data = obj;
@@ -179,14 +179,14 @@ static long sw_sync_ioctl_create_fence(struct
sw_sync_timeline *obj,
}
pt = sw_sync_pt_create(obj, data.value);
- if (pt == NULL) {
+ if (!pt) {
err = -ENOMEM;
goto err;
}
data.name[sizeof(data.name) - 1] = '\0';
fence = sync_fence_create(data.name, pt);
- if (fence == NULL) {
+ if (!fence) {
sync_pt_free(pt);
err = -ENOMEM;
goto err;
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 9a67d23..e0c1acb 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -43,7 +43,7 @@ struct sync_timeline *sync_timeline_create(const struct
sync_timeline_ops *ops,
return NULL;
obj = kzalloc(size, GFP_KERNEL);
- if (obj == NULL)
+ if (!obj)
return NULL;
kref_init(&obj->kref);
@@ -130,7 +130,7 @@ struct sync_pt *sync_pt_create(struct sync_timeline *obj,
int size)
return NULL;
pt = kzalloc(size, GFP_KERNEL);
- if (pt == NULL)
+ if (!pt)
return NULL;
spin_lock_irqsave(&obj->child_list_lock, flags);
@@ -155,7 +155,7 @@ static struct sync_fence *sync_fence_alloc(int size, const
char *name)
struct sync_fence *fence;
fence = kzalloc(size, GFP_KERNEL);
- if (fence == NULL)
+ if (!fence)
return NULL;
fence->file = anon_inode_getfile("sync_fence", &sync_fence_fops,
@@ -193,7 +193,7 @@ struct sync_fence *sync_fence_create(const char *name,
struct sync_pt *pt)
struct sync_fence *fence;
fence = sync_fence_alloc(offsetof(struct sync_fence, cbs[1]), name);
- if (fence == NULL)
+ if (!fence)
return NULL;
fence->num_fences = 1;
@@ -215,7 +215,7 @@ struct sync_fence *sync_fence_fdget(int fd)
{
struct file *file = fget(fd);
- if (file == NULL)
+ if (!file)
return NULL;
if (file->f_op != &sync_fence_fops)
@@ -262,7 +262,7 @@ struct sync_fence *sync_fence_merge(const char *name,
unsigned long size = offsetof(struct sync_fence, cbs[num_fences]);
fence = sync_fence_alloc(size, name);
- if (fence == NULL)
+ if (!fence)
return NULL;
atomic_set(&fence->status, num_fences);
@@ -583,14 +583,14 @@ static long sync_fence_ioctl_merge(struct sync_fence
*fence, unsigned long arg)
}
fence2 = sync_fence_fdget(data.fd2);
- if (fence2 == NULL) {
+ if (!fence2) {
err = -ENOENT;
goto err_put_fd;
}
data.name[sizeof(data.name) - 1] = '\0';
fence3 = sync_fence_merge(data.name, fence, fence2);
- if (fence3 == NULL) {
+ if (!fence3) {
err = -ENOMEM;
goto err_put_fence2;
}
@@ -666,7 +666,7 @@ static long sync_fence_ioctl_fence_info(struct sync_fence
*fence,
size = 4096;
data = kzalloc(size, GFP_KERNEL);
- if (data == NULL)
+ if (!data)
return -ENOMEM;
strlcpy(data->name, fence->name, sizeof(data->name));
--
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/8] fix staging:android style issue:Alignment should match open parenthesis
Signed-off-by: Peng Sun
---
drivers/staging/android/ashmem.c | 8
drivers/staging/android/lowmemorykiller.c | 4 ++--
drivers/staging/android/sync.c| 4 ++--
drivers/staging/android/sync.h| 2 +-
drivers/staging/android/timed_gpio.c | 12 +++-
5 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 1312600..d786ec1 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -834,16 +834,16 @@ static int __init ashmem_init(void)
int ret;
ashmem_area_cachep = kmem_cache_create("ashmem_area_cache",
- sizeof(struct ashmem_area),
- 0, 0, NULL);
+ sizeof(struct ashmem_area),
+ 0, 0, NULL);
if (unlikely(!ashmem_area_cachep)) {
pr_err("failed to create slab cache\n");
return -ENOMEM;
}
ashmem_range_cachep = kmem_cache_create("ashmem_range_cache",
- sizeof(struct ashmem_range),
- 0, 0, NULL);
+ sizeof(struct ashmem_range),
+ 0, 0, NULL);
if (unlikely(!ashmem_range_cachep)) {
pr_err("failed to create slab cache\n");
return -ENOMEM;
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index 872bd60..61937ab 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -104,8 +104,8 @@ static unsigned long lowmem_scan(struct shrinker *s, struct
shrink_control *sc)
}
lowmem_print(3, "lowmem_scan %lu, %x, ofree %d %d, ma %hd\n",
- sc->nr_to_scan, sc->gfp_mask, other_free,
- other_file, min_score_adj);
+sc->nr_to_scan, sc->gfp_mask, other_free,
+other_file, min_score_adj);
if (min_score_adj == OOM_SCORE_ADJ_MAX + 1) {
lowmem_print(5, "lowmem_scan %lu, %x, return 0\n",
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index f83e00c..9a67d23 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -313,7 +313,7 @@ struct sync_fence *sync_fence_merge(const char *name,
EXPORT_SYMBOL(sync_fence_merge);
int sync_fence_wake_up_wq(wait_queue_t *curr, unsigned mode,
-int wake_flags, void *key)
+ int wake_flags, void *key)
{
struct sync_fence_waiter *wait;
@@ -353,7 +353,7 @@ int sync_fence_wait_async(struct sync_fence *fence,
EXPORT_SYMBOL(sync_fence_wait_async);
int sync_fence_cancel_async(struct sync_fence *fence,
-struct sync_fence_waiter *waiter)
+ struct sync_fence_waiter *waiter)
{
unsigned long flags;
int ret = 0;
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index 61f8a3a..18a94ed 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -351,6 +351,6 @@ void sync_dump(void);
# define sync_dump()
#endif
int sync_fence_wake_up_wq(wait_queue_t *curr, unsigned mode,
-int wake_flags, void *key);
+ int wake_flags, void *key);
#endif /* _LINUX_SYNC_H */
diff --git a/drivers/staging/android/timed_gpio.c
b/drivers/staging/android/timed_gpio.c
index ce11726..5407257 100644
--- a/drivers/staging/android/timed_gpio.c
+++ b/drivers/staging/android/timed_gpio.c
@@ -76,8 +76,9 @@ static void gpio_enable(struct timed_output_dev *dev, int
value)
value = data->max_timeout;
hrtimer_start(&data->timer,
- ktime_set(value / 1000, (value % 1000) * 100),
- HRTIMER_MODE_REL);
+ ktime_set(value / 1000, (value % 1000) *
+ 100),
+ HRTIMER_MODE_REL);
}
spin_unlock_irqrestore(&data->lock, flags);
@@ -94,8 +95,9 @@ static int timed_gpio_probe(struct platform_device *pdev)
return -EBUSY;
gpio_data = devm_kzalloc(&pdev->dev,
- sizeof(struct timed_gpio_data) * pdata->num_gpios,
- GFP_KERNEL);
+sizeof(struct timed_gpio_data) *
+pdata->num_gpios,
+GFP_KERNEL);
if (!gpio_data)
return -ENOMEM;
@@ -104,7 +106,7 @@ static int timed_gpio_probe(struct platform_device *pdev)
gpio_dat = &gpio_data[i];
[PATCH 2/8] fix staging:android style issue:No space is necessary after a cast
Signed-off-by: Peng Sun
---
drivers/staging/android/ashmem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index b340ddc..1312600 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -716,7 +716,7 @@ static int ashmem_pin_unpin(struct ashmem_area *asma,
unsigned long cmd,
if (unlikely((pin.offset | pin.len) & ~PAGE_MASK))
return -EINVAL;
- if (unlikely(((__u32) -1) - pin.offset < pin.len))
+ if (unlikely(((__u32)-1) - pin.offset < pin.len))
return -EINVAL;
if (unlikely(PAGE_ALIGN(asma->size) < pin.offset + pin.len))
@@ -760,7 +760,7 @@ static long ashmem_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
ret = -EINVAL;
if (!asma->file) {
ret = 0;
- asma->size = (size_t) arg;
+ asma->size = (size_t)arg;
}
break;
case ASHMEM_GET_SIZE:
--
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 4/8] fix staging:android style issue:Prefer kernel type 'u32' over 'uint32_t'
Signed-off-by: Peng Sun
---
drivers/staging/android/lowmemorykiller.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index 61937ab..78e1281 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -42,7 +42,7 @@
#include
#include
-static uint32_t lowmem_debug_level = 1;
+static u32 lowmem_debug_level = 1;
static short lowmem_adj[6] = {
0,
1,
--
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 7/8] fix staging:android style issue:definition without comment
Signed-off-by: Peng Sun
---
drivers/staging/android/sync.h | 2 +-
drivers/staging/android/timed_gpio.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index 18a94ed..bb42923 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -94,11 +94,11 @@ struct sync_timeline {
const struct sync_timeline_ops *ops;
charname[32];
- /* protected by child_list_lock */
booldestroyed;
int context, value;
struct list_headchild_list_head;
+ /* protect field destroyed */
spinlock_t child_list_lock;
struct list_headactive_list_head;
diff --git a/drivers/staging/android/timed_gpio.c
b/drivers/staging/android/timed_gpio.c
index 5407257..5c55463 100644
--- a/drivers/staging/android/timed_gpio.c
+++ b/drivers/staging/android/timed_gpio.c
@@ -29,7 +29,7 @@
struct timed_gpio_data {
struct timed_output_dev dev;
struct hrtimer timer;
- spinlock_t lock;
+ spinlock_t lock; /* protect structure fields */
unsigned gpio;
int max_timeout;
u8 active_low;
--
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 8/8] fix staging:android style issue:Please don't use multiple blank lines
Signed-off-by: Peng Sun
---
drivers/staging/android/timed_gpio.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/android/timed_gpio.c
b/drivers/staging/android/timed_gpio.c
index 5c55463..33acbbe 100644
--- a/drivers/staging/android/timed_gpio.c
+++ b/drivers/staging/android/timed_gpio.c
@@ -25,7 +25,6 @@
#include "timed_output.h"
#include "timed_gpio.h"
-
struct timed_gpio_data {
struct timed_output_dev dev;
struct hrtimer 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 5/8] fix staging:android style issue:Please use a blank line after function/struct/union/enum declarations
Signed-off-by: Peng Sun
---
drivers/staging/android/lowmemorykiller.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index 78e1281..3f1311f 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -49,6 +49,7 @@ static short lowmem_adj[6] = {
6,
12,
};
+
static int lowmem_adj_size = 4;
static int lowmem_minfree[6] = {
3 * 512,/* 6MB */
@@ -56,8 +57,8 @@ static int lowmem_minfree[6] = {
4 * 1024, /* 16MB */
16 * 1024, /* 64MB */
};
-static int lowmem_minfree_size = 4;
+static int lowmem_minfree_size = 4;
static unsigned long lowmem_deathpending_timeout;
#define lowmem_print(level, x...) \
--
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/8] fix staging:android style issue:spaces preferred around that '-'
Signed-off-by: Peng Sun
---
drivers/staging/android/ashmem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 60200a3..b340ddc 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -618,7 +618,8 @@ static int ashmem_pin(struct ashmem_area *asma, size_t
pgstart, size_t pgend)
/* Case #3: We overlap from the rear, so adjust it */
if (range->pgend <= pgend) {
- range_shrink(range, range->pgstart, pgstart-1);
+ range_shrink(range, range->pgstart,
+pgstart - 1);
continue;
}
--
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 0/8] fix drivers/staging/android several coding style issues
patches based on linux-next next-20150825 Corrections based on checkpatch.pl with --strict Peng Sun (8): fix staging:android style issue:spaces preferred around that '-' fix staging:android style issue:No space is necessary after a cast fix staging:android style issue:Alignment should match open parenthesis fix staging:android style issue:Prefer kernel type 'u32' over 'uint32_t' fix staging:android style issue:Please use a blank line after function/struct/union/enum declarations fix staging:android style issue:Comparison to NULL could be written fix staging:android style issue:definition without comment fix staging:android style issue:Please don't use multiple blank lines drivers/staging/android/ashmem.c | 15 --- drivers/staging/android/lowmemorykiller.c | 9 + drivers/staging/android/sw_sync.c | 6 +++--- drivers/staging/android/sync.c| 22 +++--- drivers/staging/android/sync.h| 4 ++-- drivers/staging/android/timed_gpio.c | 15 --- 6 files changed, 37 insertions(+), 34 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/
Re: [PATCH] soc: qcom: smd: Use correct remote processor ID
On Tue 25 Aug 13:36 PDT 2015, Andy Gross wrote:
> This patch fixes SMEM addressing issues when remote processors need to use
> secure SMEM partitions.
>
Right, sorry for missing that remote_pid and edge_pid isn't in sync...
> Signed-off-by: Andy Gross
> ---
> .../devicetree/bindings/soc/qcom/qcom,smd.txt |7 +++
> drivers/soc/qcom/smd.c | 18 ++
> 2 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> index f65c76d..3b60702 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
> @@ -37,6 +37,12 @@ The edge is described by the following properties:
> Definition: the identifier of the remote processor in the smd channel
> allocation table
>
> +- qcom,remote-pid:
> + Usage: required
I would like to see this being optional, as this is not a property that
matters on any of the 32-bit systems (perhaps 8084?).
> + Value type:
> + Definition: the identifier for the remote processor as known by the rest
> + of the system.
> +
> = SMD DEVICES
>
> In turn, subnodes of the "edges" represent devices tied to SMD channels on
> that
> @@ -68,6 +74,7 @@ The following example represents a smd node, with one edge
> representing the
> interrupts = <0 168 1>;
> qcom,ipc = <&apcs 8 0>;
> qcom,smd-edge = <15>;
> + qcom,remote-pid = <0x>;
This looks messy, so let's make the property optional and make its
absence indicate the "global partition".
>
> rpm_requests {
> compatible = "qcom,rpm-msm8974";
> diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
[..]
> @@ -1184,6 +1187,13 @@ static int qcom_smd_parse_edge(struct device *dev,
> return -EINVAL;
> }
>
> + key = "qcom,remote-pid";
> + ret = of_property_read_u32(node, key, &edge->remote_pid);
> + if (ret) {
> + dev_err(dev, "edge missing %s property\n", key);
> + return -EINVAL;
> + }
> +
So I suggest you changing this to:
edge->remote_pid = QCOM_SMEM_HOST_ANY;
of_property_read_u32(node, "qcom,remote-pid", &edge->remote_pid);
> syscon_np = of_parse_phandle(node, "qcom,ipc", 0);
> if (!syscon_np) {
> dev_err(dev, "no qcom,ipc node\n");
Regards,
Bjorn
--
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 0/3] timer: Improve itimers scalability
On Tue, 25 Aug 2015 20:17:45 -0700 Jason Low wrote: > When running a database workload on a 16 socket machine, there were > scalability issues related to itimers. > > Commit 1018016c706f addressed the issue with the thread_group_cputimer > spinlock taking up a significant portion of total run time. > > This patch series address the other issue where a lot of time is spent > trying to acquire the sighand lock. It was found in some cases that > 200+ threads were simultaneously contending for the same sighand lock, > reducing throughput by more than 30%. Does this imply that the patchset increased the throughput of this workload by 30%? And is this test case realistic? If not, what are the benefits on a real-world workload? -- 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] ASoC: rockchip: fix a misjudgement by return
Being careless, judge the return value of snd_soc_card_jack_new
is opposite, so it should be fixed.
---
Changes in v2:
Signed-off-by: Xing Zheng
Reviewed-by: Dylan Reid
sound/soc/rockchip/rockchip_rt5645.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/rockchip/rockchip_rt5645.c
b/sound/soc/rockchip/rockchip_rt5645.c
index 3c6bb1e..adfe98c 100644
--- a/sound/soc/rockchip/rockchip_rt5645.c
+++ b/sound/soc/rockchip/rockchip_rt5645.c
@@ -118,7 +118,7 @@ static int rk_init(struct snd_soc_pcm_runtime *runtime)
SND_JACK_BTN_0 | SND_JACK_BTN_1 |
SND_JACK_BTN_2 | SND_JACK_BTN_3,
&headset_jack, NULL, 0);
- if (!ret) {
+ if (ret) {
dev_err(card->dev, "New Headset Jack failed! (%d)\n", ret);
return ret;
}
--
1.7.9.5
--
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] timer: Reduce unnecessary sighand lock contention
It was found while running a database workload on large systems that
significant time was spent trying to acquire the sighand lock.
The issue was that whenever an itimer expired, many threads ended up
simultaneously trying to send the signal. Most of the time, nothing
happened after acquiring the sighand lock because another thread
had already sent the signal and updated the "next expire" time. The
fastpath_timer_check() didn't help much since the "next expire" time
was updated later.
This patch addresses this by having the thread_group_cputimer structure
maintain a boolean to signify when a thread in the group is already
checking for process wide timers, and adds extra logic in the fastpath
to check the boolean.
Signed-off-by: Jason Low
---
include/linux/init_task.h |1 +
include/linux/sched.h |3 +++
kernel/time/posix-cpu-timers.c | 19 +--
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index d0b380e..3350c77 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -53,6 +53,7 @@ extern struct fs_struct init_fs;
.cputimer = { \
.cputime_atomic = INIT_CPUTIME_ATOMIC, \
.running= 0,\
+ .checking_timer = 0,\
}, \
INIT_PREV_CPUTIME(sig) \
.cred_guard_mutex = \
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 119823d..a6c8334 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -619,6 +619,8 @@ struct task_cputime_atomic {
* @cputime_atomic:atomic thread group interval timers.
* @running: non-zero when there are timers running and
* @cputime receives updates.
+ * @checking_timer:non-zero when a thread is in the process of
+ * checking for thread group timers.
*
* This structure contains the version of task_cputime, above, that is
* used for thread group CPU timer calculations.
@@ -626,6 +628,7 @@ struct task_cputime_atomic {
struct thread_group_cputimer {
struct task_cputime_atomic cputime_atomic;
int running;
+ int checking_timer;
};
#include
diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 535bef5..f3ddf0e 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -962,6 +962,14 @@ static void check_process_timers(struct task_struct *tsk,
unsigned long soft;
/*
+* Signify that a thread is checking for process timers.
+* The checking_timer field is only modified in this function,
+* which is called with the sighand lock held. Thus, we can
+* just use WRITE_ONCE() without any further locking.
+*/
+ WRITE_ONCE(sig->cputimer.checking_timer, 1);
+
+ /*
* Collect the current process totals.
*/
thread_group_cputimer(tsk, &cputime);
@@ -1015,6 +1023,8 @@ static void check_process_timers(struct task_struct *tsk,
sig->cputime_expires.sched_exp = sched_expires;
if (task_cputime_zero(&sig->cputime_expires))
stop_process_timers(sig);
+
+ WRITE_ONCE(sig->cputimer.checking_timer, 0);
}
/*
@@ -1132,8 +1142,13 @@ static inline int fastpath_timer_check(struct
task_struct *tsk)
}
sig = tsk->signal;
- /* Check if cputimer is running. This is accessed without locking. */
- if (READ_ONCE(sig->cputimer.running)) {
+ /*
+* Check if thread group timers expired if the cputimer is running
+* and that no other thread in the group is already checking for
+* thread group cputimers.
+*/
+ if (READ_ONCE(sig->cputimer.running) &&
+ !READ_ONCE(sig->cputimer.checking_timer)) {
struct task_cputime group_sample;
sample_cputime_atomic(&group_sample,
&sig->cputimer.cputime_atomic);
--
1.7.2.5
--
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/3] timer: Improve itimers scalability
When running a database workload on a 16 socket machine, there were scalability issues related to itimers. Commit 1018016c706f addressed the issue with the thread_group_cputimer spinlock taking up a significant portion of total run time. This patch series address the other issue where a lot of time is spent trying to acquire the sighand lock. It was found in some cases that 200+ threads were simultaneously contending for the same sighand lock, reducing throughput by more than 30%. Jason Low (3): timer: Optimize fastpath_timer_check() timer: Check thread timers only when there are active thread timers timer: Reduce unnecessary sighand lock contention include/linux/init_task.h |1 + include/linux/sched.h |3 ++ kernel/time/posix-cpu-timers.c | 44 +++ 3 files changed, 34 insertions(+), 14 deletions(-) -- 1.7.2.5 -- 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] timer: Check thread timers only when there are active thread timers
The fastpath_timer_check() contains logic to check for if any timers are set by checking if !task_cputime_zero(). Similarly, we can do this before calling check_thread_timers(). In the case where there are only process-wide timers, this will skip all the computations for the per-thread timers when there are no per-thread timers. Signed-off-by: Jason Low --- kernel/time/posix-cpu-timers.c | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c index 02596ff..535bef5 100644 --- a/kernel/time/posix-cpu-timers.c +++ b/kernel/time/posix-cpu-timers.c @@ -1168,11 +1168,13 @@ void run_posix_cpu_timers(struct task_struct *tsk) if (!lock_task_sighand(tsk, &flags)) return; /* -* Here we take off tsk->signal->cpu_timers[N] and -* tsk->cpu_timers[N] all the timers that are firing, and -* put them on the firing list. +* If there are active per-thread timers, take off +* tsk->signal->cpu_timers[N] and tsk->cpu_timers[N] all the +* timers that are firing, and put them on the firing list. */ - check_thread_timers(tsk, &firing); + if (!task_cputime_zero(&tsk->cputime_expires)) + check_thread_timers(tsk, &firing); + /* * If there are any active process wide timers (POSIX 1.b, itimers, * RLIMIT_CPU) cputimer must be running. -- 1.7.2.5 -- 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] timer: Optimize fastpath_timer_check()
In fastpath_timer_check(), the task_cputime() function is always
called to compute the utime and stime values. However, this is not
necessary if there are no per-thread timers to check for. This patch
modifies the code such that we compute the task_cputime values only
when there are per-thread timers set.
Signed-off-by: Jason Low
---
kernel/time/posix-cpu-timers.c | 15 +++
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 892e3da..02596ff 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -1117,16 +1117,15 @@ static inline int task_cputime_expired(const struct
task_cputime *sample,
static inline int fastpath_timer_check(struct task_struct *tsk)
{
struct signal_struct *sig;
- cputime_t utime, stime;
-
- task_cputime(tsk, &utime, &stime);
if (!task_cputime_zero(&tsk->cputime_expires)) {
- struct task_cputime task_sample = {
- .utime = utime,
- .stime = stime,
- .sum_exec_runtime = tsk->se.sum_exec_runtime
- };
+ struct task_cputime task_sample;
+ cputime_t utime, stime;
+
+ task_cputime(tsk, &utime, &stime);
+ task_sample.utime = utime;
+ task_sample.stime = stime;
+ task_sample.sum_exec_runtime = tsk->se.sum_exec_runtime;
if (task_cputime_expired(&task_sample, &tsk->cputime_expires))
return 1;
--
1.7.2.5
--
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: [V3 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly
Hi,
> From: Peter Zijlstra [mailto:pet...@infradead.org]
>
> On Sat, Aug 22, 2015 at 02:35:24AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > From: Peter Zijlstra [mailto:pet...@infradead.org]
> > >
> > > On Thu, Aug 06, 2015 at 02:45:43PM +0900, Hidehiro Kawai wrote:
> > > > void crash_kexec(struct pt_regs *regs)
> > > > {
> > > > + int old_cpu, this_cpu;
> > > > +
> > > > + /*
> > > > +* `old_cpu == -1' means we are the first comer and
> > > > crash_kexec()
> > > > +* was called without entering panic().
> > > > +* `old_cpu == this_cpu' means crash_kexec() was called from
> > > > panic().
> > > > +*/
> > > > + this_cpu = raw_smp_processor_id();
> > > > + old_cpu = atomic_cmpxchg(&panic_cpu, -1, this_cpu);
> > > > + if (old_cpu != -1 && old_cpu != this_cpu)
> > > > + return;
> > >
> > > This allows recursive calling of crash_kexec(), the Changelog did not
> > > mention that. Is this really required?
> >
> > What part are you arguing? Recursive call of crash_kexec() doesn't
> > happen. In the first place, one of the purpose of this patch is
> > to prevent a recursive call of crash_kexec() in the following case
> > as I stated in the description:
> >
> > CPU 0:
> > oops_end()
> > crash_kexec()
> > mutex_trylock() // acquired
> >
> > io_check_error()
> > panic()
> > crash_kexec()
> > mutex_trylock() // failed to acquire
> > infinite loop
> >
>
> Yes, but what to we want to do there? It seems to me that is wrong, we
> do not want to let a recursive crash_kexec() proceed.
>
> Whereas the condition you created explicitly allows this recursion by
> virtue of the 'old_cpu != this_cpu' check.
I understand your question. I don't intend to permit the recursive
call of crash_kexec() as for 'old_cpu != this_cpu' check. That is
needed for the case of panic() --> crash_kexec(). Since panic_cpu has
already been set to this_cpu in panic() (please see PATCH 1/4), no one
can run crash_kexec() without 'old_cpu != this_cpu' check.
If you don't like this check, I would also be able to handle this case
like below:
crash_kexec()
{
old_cpu = atomic_cmpxchg(&panic_cpu, -1, this_cpu);
if (old_cpu != -1)
return;
__crash_kexec();
}
panic()
{
atomic_cmpxchg(&panic_cpu, -1, this_cpu);
__crash_kexec();
...
Regards,
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group
Re: [PATCH V2 0/4] PCI: ACPI: Setting up DMA coherency for PCI device from _CCA attribute
Hi Arnd, On 8/26/15 01:48, Arnd Bergmann wrote: On Wednesday 26 August 2015 00:33:25 Suravee Suthikulpanit wrote: This patch adds support to setup DMA coherency for PCI device using the ACPI _CCA attribute. According to the ACPI spec, the _CCA attribute is required for ARM64. Therefore, this patch is a pre-req for ACPI PCI support for ARM64 which is currently in development. Also, this should not affect other architectures that does not define CONFIG_ACPI_CCA_REQUIRED, since the default value is coherent. We only support ACPI on SBSA compliant platforms, and SBSA mandates cache-coherent PCI, so I don't think this is actually needed, just use coherent all the time and do WARN_ON(!CCA) to catch people that try to incorrectly use ACPI on a non-SBSA platform. Arnd Thanks for pointing out. The CONFIG_ACPI_CCA_REQUIRED is already existed and selected in arch/arm64/Kconfig, and used for both PCI and non-PCI devices. I am not adding anything specific for the PCI case. Although, I think WARN_ON(!CCA) when it is required is a good idea. I'll find a proper place for it. Thanks, Suravee. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-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] usbnet: Fix a race between usbnet_stop() and the BH
From: Eugene Shatokhin
Date: Mon, 24 Aug 2015 23:13:43 +0300
> The race may happen when a device (e.g. YOTA 4G LTE Modem) is
> unplugged while the system is downloading a large file from the Net.
>
> Hardware breakpoints and Kprobes with delays were used to confirm that
> the race does actually happen.
>
> The race is on skb_queue ('next' pointer) between usbnet_stop()
> and rx_complete(), which, in turn, calls usbnet_bh().
>
> Here is a part of the call stack with the code where the changes to the
> queue happen. The line numbers are for the kernel 4.1.0:
...
It looks like this patch needs more discussion/work.
--
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: fix bug for reloading FPSIMD state after execve on cpu 0.
From: Janet Liu
If process A is running on CPU 0 and do execve syscall and after sched_exec,
dest_cpu is 0, fpsimd_state.cpu is 0. If at the time Process A get scheduled
out and after some kernel threads running on CPU 0, process A is back in CPU 0,
A's fpsimd_state.cpu is current cpu id "0", and per_cpu(fpsimd_last_state)
points A's fpsimd_state, TIF_FOREIGN_FPSTATE will be clear, kernel will not
reload the context during it return to userspace. so set the cpu's
fpsimd_last_state to NULL to avoid this.
Signed-off-by: Janet Liu
Signed-off-by: Chunyan Zhang
---
arch/arm64/kernel/fpsimd.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 44d6f75..ec58d94 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -159,6 +159,7 @@ void fpsimd_flush_thread(void)
{
memset(¤t->thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
set_thread_flag(TIF_FOREIGN_FPSTATE);
+ this_cpu_write(fpsimd_last_state, NULL);
}
/*
--
1.7.9.5
--
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] usbnet: Get EVENT_NO_RUNTIME_PM bit before it is cleared
From: Eugene Shatokhin Date: Mon, 24 Aug 2015 23:13:42 +0300 > It is needed to check EVENT_NO_RUNTIME_PM bit of dev->flags in > usbnet_stop(), but its value should be read before it is cleared > when dev->flags is set to 0. > > The problem was spotted and the fix was provided by > Oliver Neukum . > > Signed-off-by: Eugene Shatokhin Applied and queued up for -stable. -- 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/3] arm64: dts: add Hi6220 mailbox node
On Tue, 2015-08-25 at 16:37 +0100, Leif Lindholm wrote: > On Tue, Aug 25, 2015 at 04:51:22PM +0200, Ard Biesheuvel wrote: > > >>Arm kernel should either fetch memory information from > > >>efi or DT. > > > > > > Absolutely. > > > > > >>Currently arm kernel fetch both efi memory information and > > >>reserved buffer from DTB at the same time. > > > > > > No, it does not. > > > > It should not, but it does. Due to an oversight, the stub removes > > /memreserve/ entries but ignores the reserved-memory node completely. > > Urgh. > > > This was reported here in fact > > > > http://thread.gmane.org/gmane.linux.kernel.efi/5736/focus=5742 > > > > but there has not been a followup to this series. > > Are all of those patches still relevant, or did some of them go in > already? > > Haojian: can you give that patch a spin and see if it does what you > need, combined with adding the reserved areas to the UEFI memory map? > > / > Leif It's so nice. This patch is what I need. Thanks Haojian -- 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 v3] ACPI, PCI: Penalize legacy IRQ used by ACPI SCI
On 08/25/2015 04:01 PM, Thomas Gleixner wrote: > On Fri, 21 Aug 2015, Jiang Liu wrote: >> --- >> Hi Nick, >> Rafael and Thomas have concerns about the way to solve the >> regression by quirk, so could you please help to test this patch? > > Nick, can you please confirm that this works? I saw Nick said this in bugzilla: " Tested the v3 patch - it works in a Hyper-V environment. The Tulip driver loads and the NIC was successfully assigned an IP address via DHCP. " https://bugzilla.kernel.org/show_bug.cgi?id=101301#c17 Regards, Aaron -- 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] perf probe: Support probing at absolute address
On 2015/8/26 8:02, 平松雅巳 / HIRAMATU，MASAMI wrote:
From: Wang Nan [mailto:wangn...@huawei.com]
It should be useful to allow 'perf probe' probe at absolute offset of
a target. For example, when (u)probing at a instruction of a shared
object in a embedded system where debuginfo is not avaliable but we
know the offset of that instruction by manually digging.
This patch enables following perf probe command syntax:
# perf probe +0x811e6615
And
# perf probe /lib/x86_64-linux-gnu/libc-2.19.so +0xeb860
Why do we need "+" for the absolute address?
It seems that we can do it if we find that the given probe point
starts with "0x".
Thanks,
I will change 2/2 as you suggection.
However, we can only ensure that in kernel side symbol never leading
with '0x'. Although I don't think symbol leading with 0x is useful,
it is still possible for a userspace program compiled and linked by
a language other than C produces such symbol. '+' helps us separate
address and function name semantically, make us don't rely on assumption
on function names. If in future we do meet '0x' symbols, I think we still
need the '+' syntax back. But we can do it at that time.
Thank you.
In the above example, we don't need a anchor symbol, so it is possible
to compute absolute addresses using other methods and then use
'perf probe' to create the probing points.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
Cc: Ingo Molnar
Cc: Masami Hiramatsu
Cc: Namhyung Kim
---
tools/perf/util/probe-event.c | 144 +
tools/perf/util/probe-event.h | 3 +
tools/perf/util/probe-finder.c | 21 +-
3 files changed, 138 insertions(+), 30 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 6c7e538..59de69a4 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1194,9 +1194,13 @@ static int parse_perf_probe_point(char *arg, struct
perf_probe_event *pev)
*ptr++ = '\0';
}
- tmp = strdup(arg);
- if (tmp == NULL)
- return -ENOMEM;
+ if (arg[0] == '\0')
+ tmp = NULL;
+ else {
+ tmp = strdup(arg);
+ if (tmp == NULL)
+ return -ENOMEM;
+ }
if (file_spec)
pp->file = tmp;
@@ -1283,11 +1287,6 @@ static int parse_perf_probe_point(char *arg, struct
perf_probe_event *pev)
return -EINVAL;
}
- if (pp->offset && !pp->function) {
- semantic_error("Offset requires an entry function.\n");
- return -EINVAL;
- }
-
if (pp->retprobe && !pp->function) {
semantic_error("Return probe requires an entry function.\n");
return -EINVAL;
@@ -1299,6 +1298,11 @@ static int parse_perf_probe_point(char *arg, struct
perf_probe_event *pev)
return -EINVAL;
}
+ if (!pp->function && !pp->offset && !pp->file) {
+ semantic_error("Absolute address should not be zero.\n");
+ return -EINVAL;
+ }
+
pr_debug("symbol:%s file:%s line:%d offset:%lu return:%d lazy:%s\n",
pp->function, pp->file, pp->line, pp->offset, pp->retprobe,
pp->lazy_line);
@@ -1609,7 +1613,7 @@ error:
static char *synthesize_perf_probe_point(struct perf_probe_point *pp)
{
char *buf, *tmp;
- char offs[32] = "", line[32] = "", file[32] = "";
+ char offs[32] = "", line[32] = "", file[32] = "", addr[32] = "";
int ret, len;
buf = zalloc(MAX_CMDLEN);
@@ -1622,6 +1626,11 @@ static char *synthesize_perf_probe_point(struct
perf_probe_point *pp)
if (ret <= 0)
goto error;
}
+ if (!pp->function) {
+ ret = e_snprintf(addr, 32, "0x%lx", pp->offset);
+ if (ret <= 0)
+ goto error;
+ }
if (pp->line) {
ret = e_snprintf(line, 32, ":%d", pp->line);
if (ret <= 0)
@@ -1639,9 +1648,11 @@ static char *synthesize_perf_probe_point(struct
perf_probe_point *pp)
goto error;
}
- if (pp->function)
- ret = e_snprintf(buf, MAX_CMDLEN, "%s%s%s%s%s", pp->function,
-offs, pp->retprobe ? "%return" : "", line,
+ if (pp->function || pp->offset)
+ ret = e_snprintf(buf, MAX_CMDLEN, "%s%s%s%s%s",
+pp->function ? : addr,
+pp->function ? offs : "",
+pp->retprobe ? "%return" : "", line,
file);
else
ret = e_snprintf(buf, MAX_CMDLEN, "%s%s", file, line);
@@ -1786,6 +1797,11 @@ char *synthesize_probe_trace_command(struct
probe_trace_event *tev)
if (tev->uprobes)
ret = e_snprintf(buf + len, MAX_CMDLEN - len,
Re: [PATCH V1 0/3] fix clock issue for fsl,spdif
On Tue, Aug 25, 2015 at 11:45:27AM -0700, Michael Turquette wrote: > Quoting Shengjiu Wang (2015-08-11 02:26:51) > > fix clock issue for fsl,spdif > > > > Shengjiu Wang (3): > > ARM: imx6q: Add SPDIF_GCLK clock in clock tree > > ARM: imx6sl: Add SPDIF_GCLK clock in clock tree > > ARM: imx6sx: Add SPDIF_GCLK clock in clock tree > > Hello Shengjiu Wang, > > Please move the dts changes into separate patches. I can take the > changes to the clock driver and the header through the clk tree, but the > dt patches need to go through arm-soc. > > Regards, > Mike Thanks Mike. I will send another patches for dts changes. > > > > > arch/arm/boot/dts/imx6qdl.dtsi| 2 +- > > arch/arm/boot/dts/imx6sl.dtsi | 16 > > arch/arm/boot/dts/imx6sx.dtsi | 2 +- > > drivers/clk/imx/clk-imx6q.c | 4 +++- > > drivers/clk/imx/clk-imx6sl.c | 4 +++- > > drivers/clk/imx/clk-imx6sx.c | 1 + > > include/dt-bindings/clock/imx6qdl-clock.h | 3 ++- > > include/dt-bindings/clock/imx6sl-clock.h | 3 ++- > > include/dt-bindings/clock/imx6sx-clock.h | 3 ++- > > 9 files changed, 31 insertions(+), 7 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/ -- 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: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver
On 26-08-15, 09:25, Pi-Cheng Chen wrote: > The [3/3] is based on Mediatek SoC maintainer tree[1] and the patch which > introduce a new clock type[2] consumed by MT8173 cpufreq driver. So it will > cause some conflicts if it goes through your tree. I am not sure how this > should be handled, but should it be merged through Mediatek SoC maintainer > tree? Just get that applied to MTK tree, it doesn't have any dependency on rest of the patches for build/boot. The only thing is that cpufreq wouldn't work and it will work as soon as Rafael's and MTK's trees are merged by Linus. -- 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] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
On Wed, Aug 26, 2015 at 11:26:02AM +1000, Greg Ungerer wrote: > Hi Rich, > > On 21/08/15 05:11, Rich Felker wrote: > > From: Rich Felker > > > > On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to > > overlap with all but the last PAGE_SIZE bytes of the stack. This leads > > to catastrophic memory reuse/corruption if brk is used. Fix by setting > > the brk area to zero size to disable its use. > > > > Signed-off-by: Rich Felker > > It would make sense to run this by David Howells , > I think he wrote this code (added to CC list). Thanks. I have another follow-up patch to submit soon that uses the existing ELF_FDPIC_FLAG_CONSTDISP code in binfmt_elf_fdpic.c to load normal, non-FDPIC ELF files on NOMMU, so I'll make sure to CC him on that too. > I have no problem with it, so: > > Acked-by: Greg Ungerer > > > --- > > > > There is no reason for the kernel to be providing a brk area at all on > > NOMMU; the bFLT loader does not provide one, uClibc never uses brk on > > NOMMU targets, and musl libc goes out of its way to avoid using brk > > that might run into the stack. > > I recall a long time back someone was playing with the idea of setting > the brk to the unused parts of the last data area page. (Somewhat like > this code seems to be trying). That scheme still allocated the full > requested stack size (IIRC) though. And that would have been on bFLT > executables. Anyway, just some historical reference, not really > relevant now. For what it's worth, musl's malloc rounds the initial brk up to a page boundary, but the dynamic linker recovers any partial page at the end of the data segment and donates it to malloc without brk's help. So even though brk will fail and malloc will fall back to mmap, this otherwise-wasted space does get recovered and used. Rich -- 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 V2 2/4] ACPI/scan: Clean up acpi_check_dma
On Wednesday, August 26, 2015 09:00:23 AM Suravee Suthikulpanit wrote:
> Hi Rafael,
>
> On 8/26/15 06:48, Rafael J. Wysocki wrote:
>
> >[...]
> > On Wednesday, August 26, 2015 12:33:27 AM Suravee Suthikulpanit wrote:
> >> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> >> index b9657af..55cf916 100644
> >> --- a/drivers/acpi/glue.c
> >> +++ b/drivers/acpi/glue.c
> >> @@ -168,7 +168,7 @@ int acpi_bind_one(struct device *dev, struct
> >> acpi_device *acpi_dev)
> >>struct list_head *physnode_list;
> >>unsigned int node_id;
> >>int retval = -EINVAL;
> >> - bool coherent;
> >> + int coherent;
> >
> > enum, anyone? With clearly defined values?
>
> Originally I had defined
>
> enum acpi_dma_coherency {
> ACPI_DMA_NON_COHERENT,
> ACPI_DMA_COHERENT,
> APCI_DMA_NOT_SUPPORTED = -1,
> };
>
> Although, this would need to be defined in the include/linux/acpi.h, and
> will be used also for #ifndef CONFIG_ACPI code to return errors. I was
> not sure if this would be too much. If this is preferred, I'll add this
> back in.
>
> >>
> >>if (has_acpi_companion(dev)) {
> >>if (acpi_dev) {
> >> @@ -225,7 +225,8 @@ int acpi_bind_one(struct device *dev, struct
> >> acpi_device *acpi_dev)
> >>if (!has_acpi_companion(dev))
> >>ACPI_COMPANION_SET(dev, acpi_dev);
> >>
> >> - if (acpi_check_dma(acpi_dev, &coherent))
> >> + coherent = acpi_check_dma_coherency(acpi_dev);
> >> + if (coherent != -1)
> >
> > Like here I'm not sure why -1 is special?
>
> It's just another value to communicate that DMA is not supported. :)
OK
So maybe use 0/1 for the coherence thing and a proper error code
(-ENOTSUPP seems to be a good candidate) for the "no DMA" case?
Then, if you rename the local variable to something like "ret",
it will be slightly less confusing.
And instead of checking against a specific negative value, you can
simply use "if (stuff < 0)" or "if (stuff >= 0)" to check whether or
not it is supported at all.
Thanks,
Rafael
--
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] kernel: make module.c itself more explicitly non-modular
The Kconfig currently controlling compilation of this code is:
menuconfig MODULES
bool "Enable loadable module support"
...meaning that it currently is not being built as a module by anyone.
No surprise here, since modular support being a module would be an
interesting chicken before the egg problem.
Lets remove the use of module_init in this code so that when reading
the file, there is less doubt that it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit. However
one could argue that fs_initcall makes more sense for proc stuff,
and we can change the initcall order later and watch for fallout
if so desired.
We can't of course delete the module.h include in this case since it
is used all through the rest of the file.
Cc: Rusty Russell
Signed-off-by: Paul Gortmaker
---
[I was undecided as to whether we should do this in one step
or two, i.e. instead just make the change to fs_initcall here
and now, and so went with the more cautious/granular approach.]
kernel/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/module.c b/kernel/module.c
index 8f051a106676..7750bdcb12fc 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3947,7 +3947,7 @@ static int __init proc_modules_init(void)
proc_create("modules", 0, NULL, &proc_modules_operations);
return 0;
}
-module_init(proc_modules_init);
+device_initcall(proc_modules_init);
#endif
/* Given an address, look for it in the module exception tables. */
--
2.5.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 1/1] usb: dwc2: gadget: parity fix in isochronous mode
On 8/25/2015 3:00 PM, Roman Bacik wrote:
>> -Original Message-
>> From: John Youn [mailto:john.y...@synopsys.com]
>> Sent: August-25-15 2:52 PM
>> To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
>> u...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org; bcm-kernel-feedback-list; Roman Bacik
>> Subject: Re: [PATCH 1/1] usb: dwc2: gadget: parity fix in isochronous mode
>>
>> On 8/18/2015 8:45 AM, Scott Branden wrote:
>>> From: Roman Bacik
>>>
>>> USB OTG driver in isochronous mode has to set the parity of the
>>> receiving microframe. The parity is set to even by default. This
>>> causes problems for an audio gadget, if the host starts transmitting on odd
>> microframes.
>>>
>>> This fix uses Incomplete Periodic Transfer interrupt to toggle between
>>> even and odd parity until the Transfer Complete interrupt is received.
>>>
>>> Signed-off-by: Roman Bacik
>>> Reviewed-by: Abhinav Ratna
>>> Reviewed-by: Srinath Mannam
>>> Reviewed-by: Scott Branden
>>> Signed-off-by: Scott Branden
>>> ---
>>> drivers/usb/dwc2/core.h | 1 +
>>> drivers/usb/dwc2/gadget.c | 48
>> ++-
>>> drivers/usb/dwc2/hw.h | 1 +
>>> 3 files changed, 49 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h index
>>> 0ed87620..954d1cd 100644
>>> --- a/drivers/usb/dwc2/core.h
>>> +++ b/drivers/usb/dwc2/core.h
>>> @@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
>>> unsigned intperiodic:1;
>>> unsigned intisochronous:1;
>>> unsigned intsend_zlp:1;
>>> + unsigned intparity_set:1;
>>>
>>> charname[10];
>>> };
>>> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
>>> index 4d47b7c..28e4393 100644
>>> --- a/drivers/usb/dwc2/gadget.c
>>> +++ b/drivers/usb/dwc2/gadget.c
>>> @@ -1954,6 +1954,8 @@ static void s3c_hsotg_epint(struct dwc2_hsotg
>> *hsotg, unsigned int idx,
>>> ints &= ~DXEPINT_XFERCOMPL;
>>>
>>> if (ints & DXEPINT_XFERCOMPL) {
>>> + if (hs_ep->isochronous && !hs_ep->parity_set)
>>> + hs_ep->parity_set = 1;
>>> if (hs_ep->isochronous && hs_ep->interval == 1) {
>>> if (ctrl & DXEPCTL_EOFRNUM)
>>> ctrl |= DXEPCTL_SETEVENFR;
>>> @@ -2316,7 +2318,8 @@ void s3c_hsotg_core_init_disconnected(struct
>> dwc2_hsotg *hsotg,
>>> GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
>>> GINTSTS_RESETDET | GINTSTS_ENUMDONE |
>>> GINTSTS_OTGINT | GINTSTS_USBSUSP |
>>> - GINTSTS_WKUPINT,
>>> + GINTSTS_WKUPINT |
>>> + GINTSTS_INCOMPL_SOIN | GINTSTS_INCOMPL_SOOUT,
>>> hsotg->regs + GINTMSK);
>>>
>>> if (using_dma(hsotg))
>>> @@ -2581,6 +2584,48 @@ irq_retry:
>>> s3c_hsotg_dump(hsotg);
>>> }
>>>
>>> + if (gintsts & GINTSTS_INCOMPL_SOIN) {
>>> + u32 idx;
>>> + struct s3c_hsotg_ep *hs_ep;
>>> +
>>> + dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOIN\n",
>> __func__);
>>> + for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
>>> + hs_ep = hsotg->eps_in[idx];
>>> + if (hs_ep->isochronous && !hs_ep->parity_set) {
>>> + u32 epctl_reg = DIEPCTL(idx);
>>> + u32 ctrl = readl(hsotg->regs + epctl_reg);
>>> +
>>> + if (ctrl & DXEPCTL_EOFRNUM)
>>> + ctrl |= DXEPCTL_SETEVENFR;
>>> + else
>>> + ctrl |= DXEPCTL_SETODDFR;
>>> + writel(ctrl, hsotg->regs + epctl_reg);
>>> + }
>>> + }
>>> + writel(GINTSTS_INCOMPL_SOIN, hsotg->regs + GINTSTS);
>>> + }
>>> +
>>> + if (gintsts & GINTSTS_INCOMPL_SOOUT) {
>>> + u32 idx;
>>> + struct s3c_hsotg_ep *hs_ep;
>>> +
>>> + dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOOUT\n",
>> __func__);
>>> + for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
>>> + hs_ep = hsotg->eps_out[idx];
>>> + if (hs_ep->isochronous && !hs_ep->parity_set) {
>>> + u32 epctl_reg = DOEPCTL(idx);
>>> + u32 ctrl = readl(hsotg->regs + epctl_reg);
>>> +
>>> + if (ctrl & DXEPCTL_EOFRNUM)
>>> + ctrl |= DXEPCTL_SETEVENFR;
>>> + else
>>> + ctrl |= DXEPCTL_SETODDFR;
>>> + writel(ctrl, hsotg->regs + epctl_reg);
>>> + }
>>> + }
>>> + writel(GINTSTS_INCOMPL_SOOUT, hsotg->regs + GINTSTS);
>>> + }
>>> +
>>> /*
>>> * if we've had fifo events, we should try and go around the
>>> * loop again to see if there's any point in returning yet.
>>> @@ -2667,6 +2712,7 @@
Re: [PATCH v2 7/7] ARM: bcm2835: Add VC4 to the device tree.
On 08/18/2015 03:54 PM, Eric Anholt wrote: > VC4 is the GPU (display and 3D) present on the 2835. This patch and patch 1 seem OK to me, although I'll withhold any ack until the DT binding design discussion with Rob has been resolved. I haven't looked at the OF graph bindings he mentioned so have no clue about his suggestions. -- 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/
linux-next: build failure after merge of the mmc-uh tree
Hi Ulf,
After merging the mmc-uh tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "pinctrl_bind_pins" [drivers/mmc/core/mmc_core.ko] undefined!
Caused by commit
175172f6367f ("mmc: pwrseq: bind pinctrl pins before using the gpios")
I have used te mmc-uh tree from next-20150825 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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/
