On 07/23/2018 02:38 PM, Michael S. Tsirkin wrote:
> On Mon, Jul 23, 2018 at 11:58:23AM +0530, Anshuman Khandual wrote:
>> On 07/20/2018 06:46 PM, Michael S. Tsirkin wrote:
>>> On Fri, Jul 20, 2018 at 09:29:37AM +0530, Anshuman Khandual wrote:
This patch series is the follow up on the
On 07/23/2018 02:38 PM, Michael S. Tsirkin wrote:
> On Mon, Jul 23, 2018 at 11:58:23AM +0530, Anshuman Khandual wrote:
>> On 07/20/2018 06:46 PM, Michael S. Tsirkin wrote:
>>> On Fri, Jul 20, 2018 at 09:29:37AM +0530, Anshuman Khandual wrote:
This patch series is the follow up on the
The f2fs_gc() called by f2fs_balance_fs() requires to be called outside of
fi->i_gc_rwsem[WRITE], since f2fs_gc() can try to grab it in a loop.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/file.c| 2 ++
fs/f2fs/segment.c | 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git
The f2fs_gc() called by f2fs_balance_fs() requires to be called outside of
fi->i_gc_rwsem[WRITE], since f2fs_gc() can try to grab it in a loop.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/file.c| 2 ++
fs/f2fs/segment.c | 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Alan Chiang
Provide a flexible way to determine the addressing bits of eeprom.
Pass the addressing bits to driver through address-width property.
Signed-off-by: Alan Chiang
Signed-off-by: Andy Yeh
---
drivers/misc/eeprom/at24.c | 17 +
1 file changed, 17 insertions(+)
From: Alan Chiang
Provide a flexible way to determine the addressing bits of eeprom.
Pass the addressing bits to driver through address-width property.
Signed-off-by: Alan Chiang
Signed-off-by: Andy Yeh
---
drivers/misc/eeprom/at24.c | 17 +
1 file changed, 17 insertions(+)
From: Alan Chiang
Currently the only way to use a variant of a supported model with
a different address with a different address width is to define a
new compatible string and the corresponding chip data structure.
Provide a flexible way to specify the size of the address pointer
by defining a
From: Alan Chiang
Currently the only way to use a variant of a supported model with
a different address with a different address width is to define a
new compatible string and the corresponding chip data structure.
Provide a flexible way to specify the size of the address pointer
by defining a
From: Alan Chiang
The RESEND PATCH modifies the commit message and adds the Reviewed-by.
In at24.c, it uses 8-bit addressing by default. In this patch add a
property address-width that provides a flexible method to pass the
information to the driver.
Alan Chiang (2):
dt-bindings: at24: Add
From: Alan Chiang
The RESEND PATCH modifies the commit message and adds the Reviewed-by.
In at24.c, it uses 8-bit addressing by default. In this patch add a
property address-width that provides a flexible method to pass the
information to the driver.
Alan Chiang (2):
dt-bindings: at24: Add
In my testing, v9fs_fid_xattr_set will return successfully even if the
backend ext4 filesystem has no space to store xattr key-value. That will
cause inconsistent behavior between front end and back end. The reason is
that lsetxattr will be triggered by p9_client_clunk, and unfortunately we
did
In my testing, v9fs_fid_xattr_set will return successfully even if the
backend ext4 filesystem has no space to store xattr key-value. That will
cause inconsistent behavior between front end and back end. The reason is
that lsetxattr will be triggered by p9_client_clunk, and unfortunately we
did
Peter,
The problem is in this stack
start_kernel
local_irq_enable
late_time_init
sched_clock_init
generic_sched_clock_init
sched_clock_register
WARN_ON(!irqs_disabled());
Before this work, sched_clock_init() was called prior to enabling
interrupts, but now after. So, we
Peter,
The problem is in this stack
start_kernel
local_irq_enable
late_time_init
sched_clock_init
generic_sched_clock_init
sched_clock_register
WARN_ON(!irqs_disabled());
Before this work, sched_clock_init() was called prior to enabling
interrupts, but now after. So, we
On Tue, Jul 24, 2018 at 07:55:25PM -0700, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 11:51:06AM +0900, Minchan Kim wrote:
> > On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote:
> > > There is NOTHING in a union with _refcount.
> >
> > Confusing. Matthew, what am I missing?
> >
On Tue, Jul 24, 2018 at 07:55:25PM -0700, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 11:51:06AM +0900, Minchan Kim wrote:
> > On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote:
> > > There is NOTHING in a union with _refcount.
> >
> > Confusing. Matthew, what am I missing?
> >
Commit 3c07aaef6598 ("selftests: kselftest: change KSFT_SKIP=4 instead of
KSFT_PASS") reverted commit 11867a77eb85 ("selftests: kselftest framework:
change skip exit code to 0") but missed removing the comment which that
commit added, so do that now.
Signed-off-by: Thiago Jung Bauermann
---
Commit 3c07aaef6598 ("selftests: kselftest: change KSFT_SKIP=4 instead of
KSFT_PASS") reverted commit 11867a77eb85 ("selftests: kselftest framework:
change skip exit code to 0") but missed removing the comment which that
commit added, so do that now.
Signed-off-by: Thiago Jung Bauermann
---
On Wed, Jul 25, 2018 at 11:51:06AM +0900, Minchan Kim wrote:
> On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote:
> > There is NOTHING in a union with _refcount.
>
> Confusing. Matthew, what am I missing?
>
> Before:
>
> counters consumes 8 bytes
> units and _refcount consumes each
On Wed, Jul 25, 2018 at 11:51:06AM +0900, Minchan Kim wrote:
> On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote:
> > There is NOTHING in a union with _refcount.
>
> Confusing. Matthew, what am I missing?
>
> Before:
>
> counters consumes 8 bytes
> units and _refcount consumes each
On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > [ 804.485321] BUG: Bad page state in process qemu-system-x86 pfn:1c4b08e
> > [ 804.485403] page:e809312c2380 count:0 mapcount:0
> > mapping: index:0x1
> > [ 804.485483] flags: 0x17fffc8(uptodate)
> > [
On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > [ 804.485321] BUG: Bad page state in process qemu-system-x86 pfn:1c4b08e
> > [ 804.485403] page:e809312c2380 count:0 mapcount:0
> > mapping: index:0x1
> > [ 804.485483] flags: 0x17fffc8(uptodate)
> > [
On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 11:16:57AM +0900, Minchan Kim wrote:
> > On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote:
> > > On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > > > Hi Tino,
> > > >
> > > > On
On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 11:16:57AM +0900, Minchan Kim wrote:
> > On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote:
> > > On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > > > Hi Tino,
> > > >
> > > > On
On Tue, Jul 24, 2018 at 1:53 PM Andrew Morton wrote:
>
> On Tue, 24 Jul 2018 13:46:39 -0700 Cannon Matthews
> wrote:
>
> > Reimplement clear_gigantic_page() to clear gigabytes pages using the
> > non-temporal streaming store instructions that bypass the cache
> > (movnti), since an entire 1GiB
On Tue, Jul 24, 2018 at 1:53 PM Andrew Morton wrote:
>
> On Tue, 24 Jul 2018 13:46:39 -0700 Cannon Matthews
> wrote:
>
> > Reimplement clear_gigantic_page() to clear gigabytes pages using the
> > non-temporal streaming store instructions that bypass the cache
> > (movnti), since an entire 1GiB
If the userfaultfd test is run on a kernel with CONFIG_USERFAULTFD=n, it
will report that the system call is not available yet go ahead and continue
anyway:
# ./userfaultfd anon 30 1
nr_pages: 480, nr_pages_per_cpu: 120
userfaultfd syscall not available in this kernel
bounces: 0, mode:,
If the userfaultfd test is run on a kernel with CONFIG_USERFAULTFD=n, it
will report that the system call is not available yet go ahead and continue
anyway:
# ./userfaultfd anon 30 1
nr_pages: 480, nr_pages_per_cpu: 120
userfaultfd syscall not available in this kernel
bounces: 0, mode:,
On Tue, Jul 24, 2018 at 2:09 PM Matthew Wilcox wrote:
>
> On Tue, Jul 24, 2018 at 01:46:39PM -0700, Cannon Matthews wrote:
> > Reimplement clear_gigantic_page() to clear gigabytes pages using the
> > non-temporal streaming store instructions that bypass the cache
> > (movnti), since an entire
On Tue, Jul 24, 2018 at 2:09 PM Matthew Wilcox wrote:
>
> On Tue, Jul 24, 2018 at 01:46:39PM -0700, Cannon Matthews wrote:
> > Reimplement clear_gigantic_page() to clear gigabytes pages using the
> > non-temporal streaming store instructions that bypass the cache
> > (movnti), since an entire
--
DEAR FRIEND
I am MR.MUSA AHMED With the business proposal deal of US(US$18.5 mllion US
Dollars) to transfer into your account, if you are interested
get back to me for more detail.at my
E-mail (mr.musa.ahme...@gmail.com)
Best Regard
MR.MUSA AHMED
--
--
DEAR FRIEND
I am MR.MUSA AHMED With the business proposal deal of US(US$18.5 mllion US
Dollars) to transfer into your account, if you are interested
get back to me for more detail.at my
E-mail (mr.musa.ahme...@gmail.com)
Best Regard
MR.MUSA AHMED
--
If userfaultfd runs on a system that doesn't support UFFDIO_ZEROPAGE for
shared memory, it currently ends with error code 1 which indicates test
failure:
# ./userfaultfd shmem 10 10
nr_pages: 160, nr_pages_per_cpu: 80
bounces: 9, mode: rnd poll, unexpected missing ioctl for anon memory
#
Hello,
A tester ran the upstream selftest on a distro kernel and sounded the alarm when
it reported failures for features which aren't included in that kernel.
This patch set improves the test behavior in that scenario.
Thiago Jung Bauermann (3):
userfaultfd: selftest: Fix checking of
If userfaultfd runs on a system that doesn't support UFFDIO_ZEROPAGE for
shared memory, it currently ends with error code 1 which indicates test
failure:
# ./userfaultfd shmem 10 10
nr_pages: 160, nr_pages_per_cpu: 80
bounces: 9, mode: rnd poll, unexpected missing ioctl for anon memory
#
Hello,
A tester ran the upstream selftest on a distro kernel and sounded the alarm when
it reported failures for features which aren't included in that kernel.
This patch set improves the test behavior in that scenario.
Thiago Jung Bauermann (3):
userfaultfd: selftest: Fix checking of
If userfaultfd runs on a system that doesn't support some feature it is
trying to test, it currently ends with error code 1 which indicates
test failure:
# ./userfaultfd anon 10 10
nr_pages: 160, nr_pages_per_cpu: 80
bounces: 9, mode: rnd poll, userfaults: 7 59
bounces: 8, mode: poll,
If userfaultfd runs on a system that doesn't support some feature it is
trying to test, it currently ends with error code 1 which indicates
test failure:
# ./userfaultfd anon 10 10
nr_pages: 160, nr_pages_per_cpu: 80
bounces: 9, mode: rnd poll, userfaults: 7 59
bounces: 8, mode: poll,
On Wed, 25 Jul 2018 10:16:53 +0900
Masami Hiramatsu wrote:
> Hm, as far as I can see, when register_trigger() returns >= 0, it already
> calls ->init the trigger_data. This means its refcount++, and in that
> case, below patch will miss to free the trigger_data.
> How about below for tentative
On Wed, 25 Jul 2018 10:16:53 +0900
Masami Hiramatsu wrote:
> Hm, as far as I can see, when register_trigger() returns >= 0, it already
> calls ->init the trigger_data. This means its refcount++, and in that
> case, below patch will miss to free the trigger_data.
> How about below for tentative
Reimplement clear_gigantic_page() to clear gigabytes pages using the
non-temporal streaming store instructions that bypass the cache
(movnti), since an entire 1GiB region will not fit in the cache anyway.
Doing an mlock() on a 512GiB 1G-hugetlb region previously would take on
average 134 seconds,
Reimplement clear_gigantic_page() to clear gigabytes pages using the
non-temporal streaming store instructions that bypass the cache
(movnti), since an entire 1GiB region will not fit in the cache anyway.
Doing an mlock() on a 512GiB 1G-hugetlb region previously would take on
average 134 seconds,
On Wed, Jul 25, 2018 at 11:16:57AM +0900, Minchan Kim wrote:
> On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote:
> > On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > > Hi Tino,
> > >
> > > On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> > > > Hi,
> > >
Hi Junaid:
Thanks for your review.
On 7/25/2018 10:26 AM, Junaid Shahid wrote:
> On 07/24/2018 07:35 AM, Paolo Bonzini wrote:
>> On 24/07/2018 10:17, Tianyu Lan wrote:
>>> mmu_set_spte() flushes remote tlbs for drop_parent_pte/drop_spte()
>>> and set_spte() separately. This may introduce
On Wed, Jul 25, 2018 at 11:16:57AM +0900, Minchan Kim wrote:
> On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote:
> > On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > > Hi Tino,
> > >
> > > On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> > > > Hi,
> > >
Hi Junaid:
Thanks for your review.
On 7/25/2018 10:26 AM, Junaid Shahid wrote:
> On 07/24/2018 07:35 AM, Paolo Bonzini wrote:
>> On 24/07/2018 10:17, Tianyu Lan wrote:
>>> mmu_set_spte() flushes remote tlbs for drop_parent_pte/drop_spte()
>>> and set_spte() separately. This may introduce
On 07/24/2018 07:35 AM, Paolo Bonzini wrote:
> On 24/07/2018 10:17, Tianyu Lan wrote:
>> mmu_set_spte() flushes remote tlbs for drop_parent_pte/drop_spte()
>> and set_spte() separately. This may introduce redundant flush. This
>> patch is to combine these flushes and check flush request after
>>
On 07/24/2018 07:35 AM, Paolo Bonzini wrote:
> On 24/07/2018 10:17, Tianyu Lan wrote:
>> mmu_set_spte() flushes remote tlbs for drop_parent_pte/drop_spte()
>> and set_spte() separately. This may introduce redundant flush. This
>> patch is to combine these flushes and check flush request after
>>
On 2018/7/25 2:09, Christoph Hellwig wrote:
> On Tue, Jul 24, 2018 at 10:04:35PM +0800, YueHaibing wrote:
>> Sean Wang report dma_zalloc_coherent doesn't work as expect on his
>> armv7,the allocated mem is not zeroed.The reason is __alloc_from_pool
>> doesn't honor __GFP_ZERO.
>
> Please explain
On 2018/7/25 2:09, Christoph Hellwig wrote:
> On Tue, Jul 24, 2018 at 10:04:35PM +0800, YueHaibing wrote:
>> Sean Wang report dma_zalloc_coherent doesn't work as expect on his
>> armv7,the allocated mem is not zeroed.The reason is __alloc_from_pool
>> doesn't honor __GFP_ZERO.
>
> Please explain
On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > Hi Tino,
> >
> > On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> > > Hi,
> > >
> > > The first build I used was from the master branch of the mainline
On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > Hi Tino,
> >
> > On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> > > Hi,
> > >
> > > The first build I used was from the master branch of the mainline
Dear Friend,
I was shocked you stopped communicating with me, I really can't
understand your reason for doing so, but I am very happy now to inform
you about my success in getting the fund out of the bank with the help
of a staff working in the remittance office and also with the special
Dear Friend,
I was shocked you stopped communicating with me, I really can't
understand your reason for doing so, but I am very happy now to inform
you about my success in getting the fund out of the bank with the help
of a staff working in the remittance office and also with the special
On Tue, Jul 24, 2018 at 08:47:04AM +0300, Mike Rapoport wrote:
> On Mon, Jul 23, 2018 at 04:23:39PM -0500, Richard Kuo wrote:
> >
> > On Mon, Jul 16, 2018 at 10:43:18AM +0300, Mike Rapoport wrote:
> > > This patch adds registration of the system memory with memblock,
> > > eliminates
> > >
On Tue, Jul 24, 2018 at 08:47:04AM +0300, Mike Rapoport wrote:
> On Mon, Jul 23, 2018 at 04:23:39PM -0500, Richard Kuo wrote:
> >
> > On Mon, Jul 16, 2018 at 10:43:18AM +0300, Mike Rapoport wrote:
> > > This patch adds registration of the system memory with memblock,
> > > eliminates
> > >
Hi Arnd,
On 25 July 2018 at 05:33, Arnd Bergmann wrote:
> On Tue, Jul 24, 2018 at 7:07 PM, kbuild test robot wrote:
>> Hi Arnd,
>>
>> I love your patch! Yet something to improve:
>>
>> [auto build test ERROR on sof-driver-fuweitax/master]
>> [also buil
Hi Arnd,
On 25 July 2018 at 05:33, Arnd Bergmann wrote:
> On Tue, Jul 24, 2018 at 7:07 PM, kbuild test robot wrote:
>> Hi Arnd,
>>
>> I love your patch! Yet something to improve:
>>
>> [auto build test ERROR on sof-driver-fuweitax/master]
>> [also buil
On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> Hi Tino,
>
> On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> > Hi,
> >
> > The first build I used was from the master branch of the mainline kernel,
> > somewhere between rc5 and rc6. I have just reproduced the bug
On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> Hi Tino,
>
> On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> > Hi,
> >
> > The first build I used was from the master branch of the mainline kernel,
> > somewhere between rc5 and rc6. I have just reproduced the bug
On Tue, Jul 24, 2018 at 9:31 PM Andrew Morton wrote:
>
> On Tue, 24 Jul 2018 19:55:19 -0400 Pavel Tatashin
> wrote:
>
> > update_defer_init() should be called only when struct page is about to be
> > initialized. Because it counts number of initialized struct pages, but
> > there we may skip
On Tue, Jul 24, 2018 at 9:31 PM Andrew Morton wrote:
>
> On Tue, 24 Jul 2018 19:55:19 -0400 Pavel Tatashin
> wrote:
>
> > update_defer_init() should be called only when struct page is about to be
> > initialized. Because it counts number of initialized struct pages, but
> > there we may skip
)
> > +#define tlb_flush_remove_tables_local(mm) do {} while (0)
> > +#endif
>
> Is there a reason these are not inline functions, which gets us type
> checking and the like?
More to that, when building (linux-next tag: next-20180724) on arm 32
there is this build error when CON
)
> > +#define tlb_flush_remove_tables_local(mm) do {} while (0)
> > +#endif
>
> Is there a reason these are not inline functions, which gets us type
> checking and the like?
More to that, when building (linux-next tag: next-20180724) on arm 32
there is this build error when CON
Hi Tino,
On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> Hi,
>
> The first build I used was from the master branch of the mainline kernel,
> somewhere between rc5 and rc6. I have just reproduced the bug with 4.17.9
> and 4.18-rc6. Kernel messages below.
>
> The bug does not
Hi Tino,
On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> Hi,
>
> The first build I used was from the master branch of the mainline kernel,
> somewhere between rc5 and rc6. I have just reproduced the bug with 4.17.9
> and 4.18-rc6. Kernel messages below.
>
> The bug does not
On Tue, Jul 24, 2018 at 9:18 PM Andrew Morton wrote:
>
> On Tue, 24 Jul 2018 19:55:20 -0400 Pavel Tatashin
> wrote:
>
> > memmap_init_zone, is getting complex, because it is called from different
> > contexts: hotplug, and during boot, and also because it must handle some
> > architecture
On Tue, Jul 24, 2018 at 9:18 PM Andrew Morton wrote:
>
> On Tue, 24 Jul 2018 19:55:20 -0400 Pavel Tatashin
> wrote:
>
> > memmap_init_zone, is getting complex, because it is called from different
> > contexts: hotplug, and during boot, and also because it must handle some
> > architecture
On Tue, 24 Jul 2018 19:55:19 -0400 Pavel Tatashin
wrote:
> update_defer_init() should be called only when struct page is about to be
> initialized. Because it counts number of initialized struct pages, but
> there we may skip struct pages if there is some mirrored memory.
>
> So move,
On Tue, 24 Jul 2018 19:55:19 -0400 Pavel Tatashin
wrote:
> update_defer_init() should be called only when struct page is about to be
> initialized. Because it counts number of initialized struct pages, but
> there we may skip struct pages if there is some mirrored memory.
>
> So move,
Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.
Signed-off-by: Houlong Wei
Signed-off-by: HS Liao
---
drivers/soc/mediatek/Kconfig | 12 ++
drivers/soc/mediatek/Makefile |1 +
drivers/soc/mediatek/mtk-cmdq-helper.c | 291
Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.
Signed-off-by: Houlong Wei
Signed-off-by: HS Liao
---
drivers/soc/mediatek/Kconfig | 12 ++
drivers/soc/mediatek/Makefile |1 +
drivers/soc/mediatek/mtk-cmdq-helper.c | 291
This patch adds the device node of the GCE hardware for CMDQ module.
Signed-off-by: Houlong Wei
Signed-off-by: HS Liao
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
This patch adds the device node of the GCE hardware for CMDQ module.
Signed-off-by: Houlong Wei
Signed-off-by: HS Liao
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
This patch is first version of Mediatek Command Queue(CMDQ) driver. The
CMDQ is used to help write registers with critical time limitation,
such as updating display configuration during the vblank. It controls
Global Command Engine (GCE) hardware to achieve this requirement.
Currently, CMDQ only
This patch is first version of Mediatek Command Queue(CMDQ) driver. The
CMDQ is used to help write registers with critical time limitation,
such as updating display configuration during the vblank. It controls
Global Command Engine (GCE) hardware to achieve this requirement.
Currently, CMDQ only
This adds documentation for the MediaTek Global Command Engine (GCE) unit
found in MT8173 SoCs.
Signed-off-by: Houlong Wei
Signed-off-by: HS Liao
---
.../devicetree/bindings/mailbox/mtk-gce.txt| 57
include/dt-bindings/gce/mt8173-gce.h | 44
This adds documentation for the MediaTek Global Command Engine (GCE) unit
found in MT8173 SoCs.
Signed-off-by: Houlong Wei
Signed-off-by: HS Liao
---
.../devicetree/bindings/mailbox/mtk-gce.txt| 57
include/dt-bindings/gce/mt8173-gce.h | 44
Hi,
This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
to help write registers with critical time limitation, such as
updating display configuration during the vblank. It controls Global
Command Engine (GCE) hardware to achieve this requirement.
Changes since v22:
-remove
Hi,
This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
to help write registers with critical time limitation, such as
updating display configuration during the vblank. It controls Global
Command Engine (GCE) hardware to achieve this requirement.
Changes since v22:
-remove
> -Original Message-
> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: 2018年7月24日 17:22
> To: Robin Gong ; vk...@kernel.org;
> dan.j.willi...@intel.com; s.ha...@pengutronix.de; li...@armlinux.org.uk
> Cc: dmaeng...@vger.kernel.org; dl-linux-imx ;
> ker...@pengutronix.de;
Hi Alexandru,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on pci/next]
[also build test WARNING on v4.18-rc6 next-20180724]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
> -Original Message-
> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: 2018年7月24日 17:22
> To: Robin Gong ; vk...@kernel.org;
> dan.j.willi...@intel.com; s.ha...@pengutronix.de; li...@armlinux.org.uk
> Cc: dmaeng...@vger.kernel.org; dl-linux-imx ;
> ker...@pengutronix.de;
Hi Alexandru,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on pci/next]
[also build test WARNING on v4.18-rc6 next-20180724]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
[ cut here ]
WARNING: CPU: 0 PID: 0 at kernel/time/sched_clock.c:180
sched_clock_register+0x44/0x278
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.18.0-rc6-next-20180724 #1
Hardware name: ARM Integrator/CP (Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x18
[ cut here ]
WARNING: CPU: 0 PID: 0 at kernel/time/sched_clock.c:180
sched_clock_register+0x44/0x278
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.18.0-rc6-next-20180724 #1
Hardware name: ARM Integrator/CP (Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x18
On Wed, 2018-07-25 at 01:22 +0300, Georgios Tsotsos wrote:
> This patch resolves the warnings as its refereed to TODO list.
> There are also a code style issues that could be resolved via breaking
> down cvmx_usb_poll_channel().
It was better before this change.
If checkpatch caused you to
On Wed, 2018-07-25 at 01:22 +0300, Georgios Tsotsos wrote:
> This patch resolves the warnings as its refereed to TODO list.
> There are also a code style issues that could be resolved via breaking
> down cvmx_usb_poll_channel().
It was better before this change.
If checkpatch caused you to
On Tue, Jul 24, 2018 at 9:12 PM Andrew Morton wrote:
>
> On Tue, 24 Jul 2018 19:55:19 -0400 Pavel Tatashin
> wrote:
>
> > update_defer_init() should be called only when struct page is about to be
> > initialized. Because it counts number of initialized struct pages, but
> > there we may skip
On Tue, Jul 24, 2018 at 9:12 PM Andrew Morton wrote:
>
> On Tue, 24 Jul 2018 19:55:19 -0400 Pavel Tatashin
> wrote:
>
> > update_defer_init() should be called only when struct page is about to be
> > initialized. Because it counts number of initialized struct pages, but
> > there we may skip
On Tue, 24 Jul 2018 19:55:20 -0400 Pavel Tatashin
wrote:
> memmap_init_zone, is getting complex, because it is called from different
> contexts: hotplug, and during boot, and also because it must handle some
> architecture quirks. One of them is mirroed memory.
>
> Move the code that decides
On Tue, 24 Jul 2018 19:55:20 -0400 Pavel Tatashin
wrote:
> memmap_init_zone, is getting complex, because it is called from different
> contexts: hotplug, and during boot, and also because it must handle some
> architecture quirks. One of them is mirroed memory.
>
> Move the code that decides
On Tue, 24 Jul 2018 19:13:31 -0400
Steven Rostedt wrote:
> On Tue, 24 Jul 2018 17:30:08 -0400
> Steven Rostedt wrote:
>
> > I don't see where ->reg() would return anything but 1 on success. Maybe
> > I'm missing something. I'll look some more, but I'm thinking of changing
> > ->reg() to return
Hi Andreas,
On Wed, 25 Jul 2018 00:23:22 +0200 Andreas Grünbacher
wrote:
>
> 2018-07-25 0:01 GMT+02:00 Stephen Rothwell :
> > Hi all,
> >
> > Commit
> >
> > b6fbc2f6a686 ("GFS2: Fix recovery issues for spectators")
> >
> > is missing a Signed-off-by from its committer. It was rebased.
>
>
On Tue, 24 Jul 2018 19:13:31 -0400
Steven Rostedt wrote:
> On Tue, 24 Jul 2018 17:30:08 -0400
> Steven Rostedt wrote:
>
> > I don't see where ->reg() would return anything but 1 on success. Maybe
> > I'm missing something. I'll look some more, but I'm thinking of changing
> > ->reg() to return
Hi Andreas,
On Wed, 25 Jul 2018 00:23:22 +0200 Andreas Grünbacher
wrote:
>
> 2018-07-25 0:01 GMT+02:00 Stephen Rothwell :
> > Hi all,
> >
> > Commit
> >
> > b6fbc2f6a686 ("GFS2: Fix recovery issues for spectators")
> >
> > is missing a Signed-off-by from its committer. It was rebased.
>
>
On Tue, 24 Jul 2018 19:55:19 -0400 Pavel Tatashin
wrote:
> update_defer_init() should be called only when struct page is about to be
> initialized. Because it counts number of initialized struct pages, but
> there we may skip struct pages if there is some mirrored memory.
What are the runtime
On Tue, 24 Jul 2018 19:55:19 -0400 Pavel Tatashin
wrote:
> update_defer_init() should be called only when struct page is about to be
> initialized. Because it counts number of initialized struct pages, but
> there we may skip struct pages if there is some mirrored memory.
What are the runtime
On Tue, 24 Jul 2018 16:49:59 -0400
Steven Rostedt wrote:
> On Wed, 25 Jul 2018 00:09:09 +0900
> Masami Hiramatsu wrote:
>
> > Hmm, your patch seems to leak a memory since event_trigger_init() will
> > be called twice on same trigger_data (Note that event_trigger_init()
> > does not init ref
On Tue, 24 Jul 2018 16:49:59 -0400
Steven Rostedt wrote:
> On Wed, 25 Jul 2018 00:09:09 +0900
> Masami Hiramatsu wrote:
>
> > Hmm, your patch seems to leak a memory since event_trigger_init() will
> > be called twice on same trigger_data (Note that event_trigger_init()
> > does not init ref
101 - 200 of 1482 matches
Mail list logo
