Mailing List Archive

1 2 3 4 5  View All
[no subject] [ In reply to ]
unsubscribe
[no subject] [ In reply to ]
Good day Beautiful, i hope this mail meets you well? I know this may seem inappropriate so i ask for your forgiveness but i wish to get to know you better, if I may be so bold. I consider myself an easy-going man, adventurous, honest and fun loving person but I am currently looking for a relationship in which I will feel loved. I promise to answer any question that you may want to ask me...all i need is just your attention and the chance to know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from you soon.

Gavin.
[no subject] [ In reply to ]
I am in the military unit here in Afghanistan, we have some amount of funds that we want to move out of the country. My partners and I need a good partner someone we can trust. It is risk free and legal. Reply to this email: hornbeckmajordennis635@gmail.com

Regards,
Major Dennis Hornbeck.
[no subject] [ In reply to ]
I am in the military unit here in Afghanistan, we have some amount of funds that we want to move out of the country. My partners and I need a good partner someone we can trust. It is risk free and legal. Reply to this email: hornbeckmajordennis635@gmail.com

Regards,
Major Dennis Hornbeck.
[no subject] [ In reply to ]
I am in the military unit here in Afghanistan, we have some amount of funds that we want to move out of the country. My partners and I need a good partner someone we can trust. It is risk free and legal. Reply to this email: hornbeckmajordennis637@gmail.com

Regards,
Major Dennis Hornbeck.
[no subject] [ In reply to ]
Hello dear Friend,My Name is (Farouk Martins Abdel ) From Libya in
North Africa, I have escaped from my country to Togo were i am under
(Alliance missionary home) after my rebel have murdered my parents. My
late father MAJOR GENERAL, (ABDEL FATTAH YOUNES ) He held the rank of
Major General and the post of Minister of Interior, but resigned on
22nd February 2011 to defect the rebels in Libyan civil war. My father
was killed by members of an anti- Gaddafi military on 28th July
2011.When my late father was alive he deposited a large quantity of
Gold ( 125Kg) in security company here. I will like you to help me by
selling them so that you can some money to me to for my traveling
documents and air ticket to come over to your country and meet you.
Kindly Check this link in bracket ( For your own information, i want
you to view this news information about killing of my late Father,
story through BBC WORLD NEWS :
( https://www.bbc.co.uk/news/world-africa-14336122 ) and get his full
story and get back to me via this email
(fabdel@rediffmail.com) for vital information.
Thanks,
Farouk Abdel
[No Subject] [ In reply to ]
We are now providing business & personal loans:
-Rate starting at: 2.05%.
-Flexible repayment: up to 30 years.
For more information and application, please reply.

> To unsubscribe please reply with "unsubscribe" as subject.
[no subject] [ In reply to ]
unsubscribe morealaz@gmail.com
[no subject] [ In reply to ]
Bcc:
Subject: Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions
Reply-To:
In-Reply-To: <20190508124018.GA16859@bogon.m.sigxcpu.org>

Hi Leonard,,
On Wed, May 08, 2019 at 02:40:18PM +0200, Guido G?nther wrote:
> Hi Leonard,
>
> Thanks for your comments. Let's try s.th. different then: identify by
> bootrom, ocotop and anatop and fall back to ATF afterwards (I'll split
> out the DT part and add binding docs if this makes sense). I'm also
> happy to drop the whole ATF logic until mailine ATF catched up:
>
> The mainline ATF doesn't currently support the FSL_SIP_GET_SOC_INFO call
> nor does it have the code to identify different imx8mq SOC revisions so
> mimic what NXPs ATF does here.

Does this makes sense? If so I'll send this out as a series.

>
> As a fallback use ATF so we can identify new revisions once it gains
> support or when using NXPs ATF.

I'm also fine with dropping the ATF part if we don't want to depend on
it in mainline.
Cheers,
-- Guido

>
> Signed-off-by: Guido G?nther <agx@sigxcpu.org>
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 12 ++++
> drivers/soc/imx/soc-imx8.c | 68 ++++++++++++++++++-----
> 2 files changed, 67 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index 6d635ba0904c..52aa1600b33b 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -246,6 +246,18 @@
> ranges = <0x0 0x0 0x0 0x3e000000>;
> dma-ranges = <0x40000000 0x0 0x40000000 0xc0000000>;
>
> + bus@00000000 { /* ROM */
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x00000000 0x00000000 0x20000>;
> +
> + rom@00000000 {
> + compatible = "fsl,imx8mq-bootrom";
> + reg = <0x00000000 0x1e800>;
> + };
> + };
> +
> bus@30000000 { /* AIPS1 */
> compatible = "fsl,imx8mq-aips-bus", "simple-bus";
> #address-cells = <1>;
> diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c
> index fc6429f9170a..0a1fe82efe86 100644
> --- a/drivers/soc/imx/soc-imx8.c
> +++ b/drivers/soc/imx/soc-imx8.c
> @@ -3,6 +3,7 @@
> * Copyright 2019 NXP.
> */
>
> +#include <linux/arm-smccc.h>
> #include <linux/init.h>
> #include <linux/io.h>
> #include <linux/of_address.h>
> @@ -11,39 +12,80 @@
> #include <linux/platform_device.h>
> #include <linux/of.h>
>
> +#define REV_A0 0x10
> +#define REV_B0 0x20
> #define REV_B1 0x21
>
> +#define IMX8MQ_SW_INFO_A0 0x800
> +#define IMX8MQ_SW_INFO_B0 0x83C
> #define IMX8MQ_SW_INFO_B1 0x40
> #define IMX8MQ_SW_MAGIC_B1 0xff0055aa
>
> +#define FSL_SIP_GET_SOC_INFO 0xc2000006
> +
> struct imx8_soc_data {
> char *name;
> u32 (*soc_revision)(void);
> };
>
> -static u32 __init imx8mq_soc_revision(void)
> +static u32 __init imx8mq_soc_revision_atf(void)
> +{
> + struct arm_smccc_res res = { 0 };
> +
> + arm_smccc_smc(FSL_SIP_GET_SOC_INFO, 0, 0, 0, 0, 0, 0, 0, &res);
> + /*
> + * Bit [23:16] is the silicon ID
> + * Bit[7:4] is the base layer revision,
> + * Bit[3:0] is the metal layer revision
> + * e.g. 0x10 stands for Tapeout 1.0
> + */
> + return res.a0 & 0xff;
> +}
> +
> +static u32 __init imx8mq_soc_magic_node(const char *node, u32 offset)
> {
> struct device_node *np;
> - void __iomem *ocotp_base;
> + void __iomem *base;
> u32 magic;
> - u32 rev = 0;
>
> - np = of_find_compatible_node(NULL, NULL, "fsl,imx8mq-ocotp");
> + np = of_find_compatible_node(NULL, NULL, node);
> if (!np)
> - goto out;
> + return 0;
> + base = of_iomap(np, 0);
> + WARN_ON(!base);
> +
> + magic = readl_relaxed(base + offset);
> + iounmap(base);
> + of_node_put(np);
> +
> + return magic;
> +}
>
> - ocotp_base = of_iomap(np, 0);
> - WARN_ON(!ocotp_base);
> +static u32 __init imx8mq_soc_revision(void)
> +{
> + u32 magic;
>
> - magic = readl_relaxed(ocotp_base + IMX8MQ_SW_INFO_B1);
> + /* B1 revision identified by ocotop */
> + magic = imx8mq_soc_magic_node("fsl,imx8mq-ocotp", IMX8MQ_SW_INFO_B1);
> if (magic == IMX8MQ_SW_MAGIC_B1)
> - rev = REV_B1;
> + return REV_B1;
>
> - iounmap(ocotp_base);
> + /* B0 identified by bootrom */
> + magic = imx8mq_soc_magic_node("fsl,imx8mq-bootrom", IMX8MQ_SW_INFO_B0);
> + if ((magic & 0xff) == REV_B0)
> + return REV_B0;
>
> -out:
> - of_node_put(np);
> - return rev;
> + /* A0 identified by anatop */
> + magic = imx8mq_soc_magic_node("fsl,imx8mq-anatop", IMX8MQ_SW_INFO_A0);
> + if ((magic & 0xff) == REV_A0)
> + return REV_A0;
> +
> + /* Read revision from ATF as fallback */
> + magic = imx8mq_soc_revision_atf();
> + if (magic != 0xff)
> + return magic;
> +
> + return 0;
> }
>
> static const struct imx8_soc_data imx8mq_soc_data = {
> --
> 2.20.1
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions [ In reply to ]
On 22.05.2019 16:13, Guido G?nther wrote:
> Subject: Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions

Fixed subject

> On Wed, May 08, 2019 at 02:40:18PM +0200, Guido G?nther wrote:
>> Thanks for your comments. Let's try s.th. different then: identify by
>> bootrom, ocotop and anatop and fall back to ATF afterwards (I'll split
>> out the DT part and add binding docs if this makes sense). I'm also
>> happy to drop the whole ATF logic until mailine ATF catched up:
>>
>> The mainline ATF doesn't currently support the FSL_SIP_GET_SOC_INFO call
>> nor does it have the code to identify different imx8mq SOC revisions so
>> mimic what NXPs ATF does here.
>
> Does this makes sense? If so I'll send this out as a series.

Mainline ATF has recently caught up:

https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/imx/imx8m/imx8mq/imx8mq_bl31_setup.c#n52

>> As a fallback use ATF so we can identify new revisions once it gains
>> support or when using NXPs ATF.
>
> I'm also fine with dropping the ATF part if we don't want to depend on
> it in mainline.

Linux arm64 depends on ATF to implement power management via PSCI:
hotplug cpuidle and suspend.

It is not clear why Linux would avoid other services and insist on
reimplementing hardware workarounds.

--
Regards,
Leonard
[no subject] [ In reply to ]
From thomas@m3y3r.de Sun May 26 13:49:24 2019
Subject: Cocci spatch "of_table" - v5.2-rc1
To: linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Patch: Cocci
X-Mailer: DiffSplit
Message-ID: <1558871364605-1026448693-0-diffsplit-thomas@m3y3r.de>

Make sure (of/i2c/platform)_device_id tables are NULL terminated.

Found by coccinelle spatch "misc/of_table.cocci"

Run against version v5.2-rc1

P.S. If you find this email unwanted, set up a procmail rule junking on
the header:

X-Patch: Cocci
[no subject] [ In reply to ]
From thomas@m3y3r.de Sun May 26 13:49:04 2019
Subject: [PATCH] drm/omap: Make sure device_id tables are NULL terminated
To: tomi.valkeinen@ti.com, airlied@linux.ie, daniel@ffwll.ch,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Patch: Cocci
X-Mailer: DiffSplit
Message-ID: <1558871364611-249425076-1-diffsplit-thomas@m3y3r.de>
References: <1558871364605-1026448693-0-diffsplit-thomas@m3y3r.de>
In-Reply-To: <1558871364605-1026448693-0-diffsplit-thomas@m3y3r.de>
X-Serial-No: 1

Make sure (of/i2c/platform)_device_id tables are NULL terminated.

Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
---

diff -u -p a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
--- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
@@ -198,6 +198,7 @@ static const struct of_device_id omapdss
{ .compatible = "toppoly,td028ttec1" },
{ .compatible = "tpo,td028ttec1" },
{ .compatible = "tpo,td043mtea1" },
+ {},
};

static int __init omapdss_boot_init(void)
[no subject] [ In reply to ]
From thomas@m3y3r.de Sun May 26 00:14:21 2019
Subject: Cocci spatch "vma_pages" - v5.2-rc1
To: linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Patch: Cocci
X-Mailer: DiffSplit
Message-ID: <1558822461331-726613767-0-diffsplit-thomas@m3y3r.de>

Use vma_pages function on vma object instead of explicit computation.

Found by coccinelle spatch "api/vma_pages.cocci"

Run against version v5.2-rc1

P.S. If you find this email unwanted, set up a procmail rule junking on
the header:

X-Patch: Cocci
[no subject] [ In reply to ]
From thomas@m3y3r.de Sun May 26 00:13:26 2019
Subject: [PATCH] vfio-pci/nvlink2: Use vma_pages function instead of explicit
computation
To: alex.williamson@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Patch: Cocci
X-Mailer: DiffSplit
Message-ID: <1558822461341-1674464153-1-diffsplit-thomas@m3y3r.de>
References: <1558822461331-726613767-0-diffsplit-thomas@m3y3r.de>
In-Reply-To: <1558822461331-726613767-0-diffsplit-thomas@m3y3r.de>
X-Serial-No: 1

Use vma_pages function on vma object instead of explicit computation.

Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
---

diff -u -p a/drivers/vfio/pci/vfio_pci_nvlink2.c b/drivers/vfio/pci/vfio_pci_nvlink2.c
--- a/drivers/vfio/pci/vfio_pci_nvlink2.c
+++ b/drivers/vfio/pci/vfio_pci_nvlink2.c
@@ -161,7 +161,7 @@ static int vfio_pci_nvgpu_mmap(struct vf

atomic_inc(&data->mm->mm_count);
ret = (int) mm_iommu_newdev(data->mm, data->useraddr,
- (vma->vm_end - vma->vm_start) >> PAGE_SHIFT,
+ vma_pages(vma),
data->gpu_hpa, &data->mem);

trace_vfio_pci_nvgpu_mmap(vdev->pdev, data->gpu_hpa, data->useraddr,
[no subject] [ In reply to ]
I am in the military unit here in Afghanistan, we have some amount of funds that we want to move out of the country. My partners and I need a good partner someone we can trust. It is risk free and legal. Reply to this email: hornbeckmajordennis637@gmail.com

Regards,
Major Dennis Hornbeck.
[no subject] [ In reply to ]
I am in the military unit here in Afghanistan, we have some amount of funds that we want to move out of the country. My partners and I need a good partner someone we can trust. It is risk free and legal. Reply to this email: hornbeckmajordennis634@gmail.com


Regards,
Major Dennis Hornbeck.
Re: your patch [ In reply to ]
On Sun, 26 May 2019 13:44:04 +0200
"Thomas Meyer" <thomas@m3y3r.de> wrote:

> From thomas@m3y3r.de Sun May 26 00:13:26 2019
> Subject: [PATCH] vfio-pci/nvlink2: Use vma_pages function instead of explicit
> computation
> To: alex.williamson@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org
> Content-Type: text/plain; charset="UTF-8"
> Mime-Version: 1.0
> Content-Transfer-Encoding: 8bit
> X-Patch: Cocci
> X-Mailer: DiffSplit
> Message-ID: <1558822461341-1674464153-1-diffsplit-thomas@m3y3r.de>
> References: <1558822461331-726613767-0-diffsplit-thomas@m3y3r.de>
> In-Reply-To: <1558822461331-726613767-0-diffsplit-thomas@m3y3r.de>
> X-Serial-No: 1

Hi,

some kind of accident seems to have happened to your patch... maybe the
missing colon after the 'From'?

>
> Use vma_pages function on vma object instead of explicit computation.
>
> Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
> ---
>
> diff -u -p a/drivers/vfio/pci/vfio_pci_nvlink2.c b/drivers/vfio/pci/vfio_pci_nvlink2.c
> --- a/drivers/vfio/pci/vfio_pci_nvlink2.c
> +++ b/drivers/vfio/pci/vfio_pci_nvlink2.c
> @@ -161,7 +161,7 @@ static int vfio_pci_nvgpu_mmap(struct vf
>
> atomic_inc(&data->mm->mm_count);
> ret = (int) mm_iommu_newdev(data->mm, data->useraddr,
> - (vma->vm_end - vma->vm_start) >> PAGE_SHIFT,
> + vma_pages(vma),
> data->gpu_hpa, &data->mem);
>
> trace_vfio_pci_nvgpu_mmap(vdev->pdev, data->gpu_hpa, data->useraddr,

The change looks good to me.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>
[no subject] [ In reply to ]
Hey Linus,

A small bit more lively this week but not majorly so. I'm away in
Japan next week for family holiday, so I'll be pretty disconnected,
I've asked Daniel to do fixes for the week while I'm out.

core:
- Allow fb changes in async commits (drivers as well)

udmabuf:
- Unmap scatterlist when unmapping udmabuf

komeda:
- oops, dma mapping and warning fixes

arm-hdlcd:
- clock fixes,
- mode validation fix

i915:
- Add a missing Icelake workaround
- GVT - DMA map fault fix and enforcement fixes

Dave.
amdgpu:
- DCE resume fix
- New raven variation updates



drm-fixes-2019-06-07:
drm i915, amdgpu, arm display, atomic update fixes
The following changes since commit f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a:

Linux 5.2-rc3 (2019-06-02 13:55:33 -0700)

are available in the Git repository at:

git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-06-07

for you to fetch changes up to e659b4122cf9e0938b80215de6c06823fb4cf796:

Merge tag 'drm-intel-fixes-2019-06-06' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2019-06-07
10:41:33 +1000)

----------------------------------------------------------------
drm i915, amdgpu, arm display, atomic update fixes

----------------------------------------------------------------
Aleksei Gimbitskii (2):
drm/i915/gvt: Check if cur_pt_type is valid
drm/i915/gvt: Assign NULL to the pointer after memory free.

Chengming Gui (1):
drm/amd/powerplay: add set_power_profile_mode for raven1_refresh

Colin Xu (3):
drm/i915/gvt: Update force-to-nonpriv register whitelist
drm/i915/gvt: Fix GFX_MODE handling
drm/i915/gvt: Fix vGPU CSFE_CHICKEN1_REG mmio handler

Dan Carpenter (1):
drm/komeda: Potential error pointer dereference

Dave Airlie (5):
Merge tag 'drm-intel-fixes-2019-06-03' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
Merge branch 'drm-fixes-5.2' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
Merge tag 'drm-misc-fixes-2019-06-05' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Merge branch 'malidp-fixes' of git://linux-arm.org/linux-ld into drm-fixes
Merge tag 'drm-intel-fixes-2019-06-06' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Gao, Fred (1):
drm/i915/gvt: Fix cmd length of VEB_DI_IECP

Helen Koike (5):
drm/rockchip: fix fb references in async update
drm/amd: fix fb references in async update
drm/msm: fix fb references in async update
drm/vc4: fix fb references in async update
drm: don't block fb changes for async plane updates

Joonas Lahtinen (2):
Merge tag 'gvt-fixes-2019-05-30' of
https://github.com/intel/gvt-linux into drm-intel-fixes
Merge tag 'gvt-fixes-2019-06-05' of
https://github.com/intel/gvt-linux into drm-intel-fixes

Louis Li (1):
drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2)

Lowry Li (Arm Technology China) (1):
drm/komeda: fixing of DMA mapping sg segment warning

Lucas Stach (1):
udmabuf: actually unmap the scatterlist

Prike Liang (1):
drm/amd/amdgpu: add RLC firmware to support raven1 refresh

Robin Murphy (2):
drm/arm/hdlcd: Actually validate CRTC modes
drm/arm/hdlcd: Allow a bit of clock tolerance

Tina Zhang (1):
drm/i915/gvt: Initialize intel_gvt_gtt_entry in stack

Tvrtko Ursulin (1):
drm/i915/icl: Add WaDisableBankHangMode

Weinan Li (1):
drm/i915/gvt: add F_CMD_ACCESS flag for wa regs

Wen He (1):
drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 times

Xiaolin Zhang (1):
drm/i915/gvt: save RING_HEAD into vreg when vgpu switched out

Xiong Zhang (1):
drm/i915/gvt: refine ggtt range validation

YueHaibing (1):
drm/komeda: remove set but not used variable 'kcrtc'

james qian wang (Arm Technology China) (1):
drm/komeda: Constify the usage of komeda_component/pipeline/dev_funcs

drivers/dma-buf/udmabuf.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 15 +++++++
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 4 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 12 ++++-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-
drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c | 1 +
drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 31 +++++++++++--
drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 +
.../gpu/drm/arm/display/komeda/d71/d71_component.c | 8 ++--
drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 4 +-
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +-
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 6 ++-
drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 8 ++--
.../gpu/drm/arm/display/komeda/komeda_pipeline.c | 4 +-
.../gpu/drm/arm/display/komeda/komeda_pipeline.h | 10 ++---
drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 4 +-
drivers/gpu/drm/arm/hdlcd_crtc.c | 14 +++---
drivers/gpu/drm/arm/malidp_drv.c | 13 +++++-
drivers/gpu/drm/drm_atomic_helper.c | 22 +++++-----
drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
drivers/gpu/drm/i915/gvt/gtt.c | 38 +++++++++++-----
drivers/gpu/drm/i915/gvt/handlers.c | 49 ++++++++++++++++++---
drivers/gpu/drm/i915/gvt/reg.h | 2 +
drivers/gpu/drm/i915/gvt/scheduler.c | 25 +++++++++++
drivers/gpu/drm/i915/gvt/scheduler.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 3 ++
drivers/gpu/drm/i915/intel_workarounds.c | 6 +++
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4 ++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 51 +++++++++++-----------
drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
include/drm/drm_modeset_helper_vtables.h | 8 ++++
33 files changed, 268 insertions(+), 99 deletions(-)
[no subject] [ In reply to ]
unsubscribe
[no subject] [ In reply to ]
On Wed, 29 May 2019 10:45:52 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 29 May 2019 11:31:23 +0200
> Thomas Preisner <linux@tpreisner.de> wrote:
>
> > The "oneshot" tracer records every address (ip, parent_ip) exactly
> > once.
> > As a result, "oneshot" can be used to efficiently create kernel
> > function
> > coverage/usage reports such as in undertaker-tailor[0].
> >
> > In order to provide this functionality, "oneshot" uses a
> > configurable hashset for blacklisting already recorded addresses. This
> > way, no user space application is required to parse the function
> > tracer's output and to deactivate functions after they have been
> > recorded once. Additionally, the tracer's output is reduced to a bare
> > mininum so that it can be passed directly to undertaker-tailor.
> >
> > Further information regarding this oneshot function tracer can also be
> > found at [1].
> >
> > [0]: https://undertaker.cs.fau.de
> > [1]: https://tpreisner.de/pub/ba-thesis.pdf
> >
> > Signed-off-by: Thomas Preisner <linux@tpreisner.de>
> >
>
> Hi,
>
> If you are only interested in seeing what functions are called (and
> don't care about the order), why not just make another function
> profiler (see register_ftrace_profiler and friends)? Then you could
> just list the hash table entries instead of having to record into the
> ftrace ring buffer.
>
> -- Steve
Hello,

thank you very much for your feedback. According to it, I have revised
my patch to use the existing stat_tracer infrastructure which is also
used by the previously mentioned ftrace_profiler. As a result, my
oneshot profiler no longer uses the ringbuffer to store traced
functions. Instead, the hashsets are read directly and added into an
additional hashset to remove duplicate entries (over cpu cores)
altogether.

However, due to there not being any mechanism (that I am aware of) to
activate such stat tracers via kernel commandline this oneshot profiler
is now always active when selected. Therefore, it is no longer possible
to disable this tracer during runtime and thus, allocated memory is no
longer freed.

Yours sincerely,
Thomas Preisner
Re: [PATCH] ftrace: add simple oneshot function tracer [ In reply to ]
On Tue, 11 Jun 2019 22:33:11 +0200
Thomas Preisner <linux@tpreisner.de> wrote:

> However, due to there not being any mechanism (that I am aware of) to
> activate such stat tracers via kernel commandline this oneshot profiler
> is now always active when selected. Therefore, it is no longer possible
> to disable this tracer during runtime and thus, allocated memory is no
> longer freed.

What do you mean? The function profile has its own file to enable it:

echo 1 > /sys/kernel/tracing/function_profile_enabled

And disable it:

echo 0 > /sys/kernel/tracing/function_profile_enabled

-- Steve
[no subject] [ In reply to ]
--
Greetings,

I have an intending proposal for you please i need you to contact my
private

E-mail (dralbertddzongo@gmail.com) for more updates,

Best Wishes.

DR ALBERT ZONGO

--
[no subject] [ In reply to ]
--
Greetings,

I have an intending proposal for you please i need you to contact my
private

E-mail (dralbertddzongo@gmail.com) for more updates,

Best Wishes.

DR ALBERT ZONGO

--
[no subject] [ In reply to ]
????????;

? ????? ???????? ????? ???????? ????? ?????????, ??????? ?????????? 5 ??, ??? ?????????? ???????????????, ??????? ? ????????? ????? ???????? ?? 10,9 ??. ????????, ?? ?? ??????? ?????????? ??? ???????? ????? ?????, ???? ?? ?? ??????????? ???? ?????. ????? ??????????? ???? ???????? ????, ????????? ????????? ?????????? ????:

????????:
??? ????????????:
??????:
??????????? ??????:
??. ?????:
???????:

???? ?? ?? ??????? ??????????? ???? ???????? ????, ??? ???????? ???? ????? ????????!

???????? ????????? ?? ??????????.
??? ?????????????: en: 006,524.RU
??????????? ????????? ????? © 2019

????????? ???
????????? ?????????????.
[no subject] [ In reply to ]
ATENCIÓN;

Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:

nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:

Si usted no puede revalidar su buzón, el buzón se deshabilitará!

Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico ©2019

¡gracias
Sistemas administrador

1 2 3 4 5  View All