Hi,
On 21 December 2016 at 15:58, Chanwoo Choi wrote:
> Hi,
>
> On 2016년 12월 21일 16:53, Baolin Wang wrote:
>> Hi,
>>
>> On 21 December 2016 at 15:20, Chanwoo Choi wrote:
>>> Hi,
>>>
>>> On 2016년 12월 21일 15:10, Baolin Wang wrote:
Current there
Hi,
On 21 December 2016 at 15:58, Chanwoo Choi wrote:
> Hi,
>
> On 2016년 12월 21일 16:53, Baolin Wang wrote:
>> Hi,
>>
>> On 21 December 2016 at 15:20, Chanwoo Choi wrote:
>>> Hi,
>>>
>>> On 2016년 12월 21일 15:10, Baolin Wang wrote:
Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP"
On Tue 20-12-16 14:54:35, Mel Gorman wrote:
> On Tue, Dec 20, 2016 at 03:35:02PM +0100, Michal Hocko wrote:
> > On Tue 20-12-16 14:28:45, Mel Gorman wrote:
> > > On Tue, Dec 20, 2016 at 02:26:43PM +0100, Michal Hocko wrote:
> > > > On Tue 20-12-16 13:10:40, Mel Gorman wrote:
> > > > > On Tue, Dec
On Tue 20-12-16 14:54:35, Mel Gorman wrote:
> On Tue, Dec 20, 2016 at 03:35:02PM +0100, Michal Hocko wrote:
> > On Tue 20-12-16 14:28:45, Mel Gorman wrote:
> > > On Tue, Dec 20, 2016 at 02:26:43PM +0100, Michal Hocko wrote:
> > > > On Tue 20-12-16 13:10:40, Mel Gorman wrote:
> > > > > On Tue, Dec
Hi,
On 2016년 12월 21일 16:53, Baolin Wang wrote:
> Hi,
>
> On 21 December 2016 at 15:20, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2016년 12월 21일 15:10, Baolin Wang wrote:
>>> Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP" which
>>> both seem to suggest a standard
Hi,
On 2016년 12월 21일 16:53, Baolin Wang wrote:
> Hi,
>
> On 21 December 2016 at 15:20, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2016년 12월 21일 15:10, Baolin Wang wrote:
>>> Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP" which
>>> both seem to suggest a standard downstream port. But there
Hi,
On 21 December 2016 at 15:29, Chanwoo Choi wrote:
> Hi,
>
> On 2016년 12월 21일 15:10, Baolin Wang wrote:
>> According to the documentation, we should set the EXTCON_USB when
>> one SDP charger connector was reported.
>>
>> Signed-off-by: Baolin Wang
Hi,
On 21 December 2016 at 15:29, Chanwoo Choi wrote:
> Hi,
>
> On 2016년 12월 21일 15:10, Baolin Wang wrote:
>> According to the documentation, we should set the EXTCON_USB when
>> one SDP charger connector was reported.
>>
>> Signed-off-by: Baolin Wang
>> ---
>>
Hi,
On 21 December 2016 at 15:22, Chanwoo Choi wrote:
> Hi,
>
> On 2016년 12월 21일 15:10, Baolin Wang wrote:
>> According to the documentation, we should set the EXTCON_USB when
>> one SDP charger connector was reported.
>>
>> Signed-off-by: Baolin Wang
Hi,
On 21 December 2016 at 15:22, Chanwoo Choi wrote:
> Hi,
>
> On 2016년 12월 21일 15:10, Baolin Wang wrote:
>> According to the documentation, we should set the EXTCON_USB when
>> one SDP charger connector was reported.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> drivers/extcon/extcon-axp288.c |
Hi,
On 21 December 2016 at 15:20, Chanwoo Choi wrote:
> Hi,
>
> On 2016년 12월 21일 15:10, Baolin Wang wrote:
>> Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP" which
>> both seem to suggest a standard downstream port. But there is no
>> documentation describing
Hi,
On 21 December 2016 at 15:20, Chanwoo Choi wrote:
> Hi,
>
> On 2016년 12월 21일 15:10, Baolin Wang wrote:
>> Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP" which
>> both seem to suggest a standard downstream port. But there is no
>> documentation describing how these relate.
>>
>>
From: Gabor Juhos
These quirks do not effect small small plastic routers. These routers tend
to have very little flash space. This patch adds a new option that allows
us to build a kernel without including the common quirks, thus saving us
valuable flash space.
When building
From: Gabor Juhos
These quirks do not effect small small plastic routers. These routers tend
to have very little flash space. This patch adds a new option that allows
us to build a kernel without including the common quirks, thus saving us
valuable flash space.
When building an image for a
On Tue 20-12-16 16:48:23, Wei Yang wrote:
> On Mon, Dec 19, 2016 at 04:21:57PM +0100, Michal Hocko wrote:
> >On Sun 18-12-16 14:47:50, Wei Yang wrote:
> >> memblock_reserve() may fail in case there is not enough regions.
> >
> >Have you seen this happenning in the real setups or this is a
On Tue 20-12-16 16:48:23, Wei Yang wrote:
> On Mon, Dec 19, 2016 at 04:21:57PM +0100, Michal Hocko wrote:
> >On Sun 18-12-16 14:47:50, Wei Yang wrote:
> >> memblock_reserve() may fail in case there is not enough regions.
> >
> >Have you seen this happenning in the real setups or this is a
On Tue, Dec 20, 2016 at 12:02:27AM -0200, Mauricio Faria de Oliveira wrote:
> When a SCSI command (e.g., read operation) is partially completed
> with good status and residual bytes (i.e., not all the bytes from
> the specified transfer length were transferred) the SCSI midlayer
> will update the
On Tue, Dec 20, 2016 at 12:02:27AM -0200, Mauricio Faria de Oliveira wrote:
> When a SCSI command (e.g., read operation) is partially completed
> with good status and residual bytes (i.e., not all the bytes from
> the specified transfer length were transferred) the SCSI midlayer
> will update the
On Tue 20-12-16 16:35:40, Wei Yang wrote:
> On Mon, Dec 19, 2016 at 04:15:14PM +0100, Michal Hocko wrote:
> >On Sun 18-12-16 14:47:49, Wei Yang wrote:
> >> The base address is already guaranteed to be in the region by
> >> memblock_search().
> >
>
> Hi, Michal
>
> Nice to receive your comment.
>
On Tue 20-12-16 16:35:40, Wei Yang wrote:
> On Mon, Dec 19, 2016 at 04:15:14PM +0100, Michal Hocko wrote:
> >On Sun 18-12-16 14:47:49, Wei Yang wrote:
> >> The base address is already guaranteed to be in the region by
> >> memblock_search().
> >
>
> Hi, Michal
>
> Nice to receive your comment.
>
Hi, Kees and Emese
I just helped to back port the commit here:
https://github.com/acpica/acpica/pull/196/commits/5e64857f
If you can see something wrong in it, please let me know.
Thanks and best regards
Lv
> From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv
> Subject: Re:
Hi, Kees and Emese
I just helped to back port the commit here:
https://github.com/acpica/acpica/pull/196/commits/5e64857f
If you can see something wrong in it, please let me know.
Thanks and best regards
Lv
> From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv
> Subject: Re:
TL;DR
there is another version of the debugging patch. Just revert the
previous one and apply this one instead. It's still not clear what
is going on but I suspect either some misaccounting or unexpeted
pages on the LRU lists. I have added one more tracepoint, so please
enable also
TL;DR
there is another version of the debugging patch. Just revert the
previous one and apply this one instead. It's still not clear what
is going on but I suspect either some misaccounting or unexpeted
pages on the LRU lists. I have added one more tracepoint, so please
enable also
On 21/12/2016 08:33, Marek Vasut wrote:
> On 12/21/2016 08:23 AM, John Crispin wrote:
>> From: André Valentin
>>
>> This patch adds support for a new macronix spi flash chip. We have had this
>> patch inside our tree for a while and people are actively using routers
>>
On 21/12/2016 08:33, Marek Vasut wrote:
> On 12/21/2016 08:23 AM, John Crispin wrote:
>> From: André Valentin
>>
>> This patch adds support for a new macronix spi flash chip. We have had this
>> patch inside our tree for a while and people are actively using routers
>> with this chip.
>>
>>
On 12/21/2016 08:23 AM, John Crispin wrote:
> From: André Valentin
>
> This patch adds support for a new macronix spi flash chip. We have had this
> patch inside our tree for a while and people are actively using routers
> with this chip.
>
> Signed-off-by: John Crispin
On 12/21/2016 08:23 AM, John Crispin wrote:
> From: André Valentin
>
> This patch adds support for a new macronix spi flash chip. We have had this
> patch inside our tree for a while and people are actively using routers
> with this chip.
>
> Signed-off-by: John Crispin
> Signed-off-by: André
On 12/21/2016 08:23 AM, John Crispin wrote:
> From: Ash Benz
>
> This patch adds support for a new macronix spi flash chip.
> We have had this
> patch inside our tree for a while and people are actively using routers
> with this chip.
I think this information shouldn't be part
On 12/21/2016 08:23 AM, John Crispin wrote:
> From: Ash Benz
>
> This patch adds support for a new macronix spi flash chip.
> We have had this
> patch inside our tree for a while and people are actively using routers
> with this chip.
I think this information shouldn't be part of the commit
On Tue, Dec 20, 2016 at 09:24:53AM -0800, Stephen Hemminger wrote:
> On Tue, 20 Dec 2016 18:55:49 +0300
> Roman Kagan wrote:
>
> > Move definitions related to the Hyper-V SynIC event flags to a header
> > where they can be consumed by userspace.
> >
> > While doing so,
On Tue, Dec 20, 2016 at 09:24:53AM -0800, Stephen Hemminger wrote:
> On Tue, 20 Dec 2016 18:55:49 +0300
> Roman Kagan wrote:
>
> > Move definitions related to the Hyper-V SynIC event flags to a header
> > where they can be consumed by userspace.
> >
> > While doing so, also clean up their use
Hi,
On 2016년 12월 21일 15:10, Baolin Wang wrote:
> According to the documentation, we should set the EXTCON_USB when
> one SDP charger connector was reported.
>
> Signed-off-by: Baolin Wang
> ---
> drivers/phy/phy-rockchip-inno-usb2.c |7 ++-
> 1 file changed, 6
Hi,
On 2016년 12월 21일 15:10, Baolin Wang wrote:
> According to the documentation, we should set the EXTCON_USB when
> one SDP charger connector was reported.
>
> Signed-off-by: Baolin Wang
> ---
> drivers/phy/phy-rockchip-inno-usb2.c |7 ++-
> 1 file changed, 6 insertions(+), 1
From: André Valentin
This patch adds support for a new macronix spi flash chip. We have had this
patch inside our tree for a while and people are actively using routers
with this chip.
Signed-off-by: John Crispin
Signed-off-by: André Valentin
From: André Valentin
This patch adds support for a new macronix spi flash chip. We have had this
patch inside our tree for a while and people are actively using routers
with this chip.
Signed-off-by: John Crispin
Signed-off-by: André Valentin
---
Changes in V2
* add description
* add SECT_4K
From: "Larry D. Pinney"
Add Support for the ESMT_F25L32QA and ESMT_F25L64QA
These are 4MB and 8MB SPI NOR Chips from Elite Semiconductor Memory
Technology
Acked-by: Marek Vasut
Signed-off-by: John Crispin
Signed-off-by: Larry D. Pinney
From: "Larry D. Pinney"
Add Support for the ESMT_F25L32QA and ESMT_F25L64QA
These are 4MB and 8MB SPI NOR Chips from Elite Semiconductor Memory
Technology
Acked-by: Marek Vasut
Signed-off-by: John Crispin
Signed-off-by: Larry D. Pinney
---
drivers/mtd/spi-nor/spi-nor.c |2 ++
1 file
From: Ash Benz
This patch adds support for a new macronix spi flash chip. We have had this
patch inside our tree for a while and people are actively using routers
with this chip.
Signed-off-by: John Crispin
Signed-off-by: Ash Benz
---
Changes
From: Ash Benz
This patch adds support for a new macronix spi flash chip. We have had this
patch inside our tree for a while and people are actively using routers
with this chip.
Signed-off-by: John Crispin
Signed-off-by: Ash Benz
---
Changes in V2
* add description
These have been lingering inside the owrt and lede trees for a while.
André Valentin (1):
mtd: spi-nor: add support for macronix mx25u3235f
Ash Benz (1):
mtd: spi-nor: add support for macronix mx25u25635f
Larry D. Pinney (1):
mtd: spi-nor: add support for ESMT_f25l32qa and ESMT_f25l64qa
These have been lingering inside the owrt and lede trees for a while.
André Valentin (1):
mtd: spi-nor: add support for macronix mx25u3235f
Ash Benz (1):
mtd: spi-nor: add support for macronix mx25u25635f
Larry D. Pinney (1):
mtd: spi-nor: add support for ESMT_f25l32qa and ESMT_f25l64qa
Hi,
On 2016년 12월 21일 15:10, Baolin Wang wrote:
> According to the documentation, we should set the EXTCON_USB when
> one SDP charger connector was reported.
>
> Signed-off-by: Baolin Wang
> ---
> drivers/extcon/extcon-axp288.c |7 ++-
> 1 file changed, 6
Hi,
On 2016년 12월 21일 15:10, Baolin Wang wrote:
> According to the documentation, we should set the EXTCON_USB when
> one SDP charger connector was reported.
>
> Signed-off-by: Baolin Wang
> ---
> drivers/extcon/extcon-axp288.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
On Tue 20-12-16 14:39:19, Thomas Casey wrote:
> Fixes two instances of EXPORT_SYMBOL not being called immediately after
> the initialization of its argument
What does this fix actually?
> Signed-off-by: Thomas Casey
> ---
> kernel/sys.c | 6 ++
> 1 file changed, 2
On Tue 20-12-16 14:39:19, Thomas Casey wrote:
> Fixes two instances of EXPORT_SYMBOL not being called immediately after
> the initialization of its argument
What does this fix actually?
> Signed-off-by: Thomas Casey
> ---
> kernel/sys.c | 6 ++
> 1 file changed, 2 insertions(+), 4
Hi,
On 2016년 12월 21일 15:10, Baolin Wang wrote:
> Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP" which
> both seem to suggest a standard downstream port. But there is no
> documentation describing how these relate.
>
> Thus add documentation to describe EXTCON_CHG_USB_SDP should
Hi,
On 2016년 12월 21일 15:10, Baolin Wang wrote:
> Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP" which
> both seem to suggest a standard downstream port. But there is no
> documentation describing how these relate.
>
> Thus add documentation to describe EXTCON_CHG_USB_SDP should
On 12/21/2016 4:20 AM, Stephen Boyd wrote:
> On 12/18, Imran Khan wrote:
>>
>> I had discussed this with Bjorn and it was recommended to keep it out of
>> smem.h. If needed I can move it back there.
>
> Ok no worries from me then if this has already been discussed.
>
>>
>> Yes. The numbers used
On 12/21/2016 4:20 AM, Stephen Boyd wrote:
> On 12/18, Imran Khan wrote:
>>
>> I had discussed this with Bjorn and it was recommended to keep it out of
>> smem.h. If needed I can move it back there.
>
> Ok no worries from me then if this has already been discussed.
>
>>
>> Yes. The numbers used
Hi Sven,
[auto build test ERROR on linus/master]
[also build test ERROR on next-20161221]
[cannot apply to v4.9]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Sven,
[auto build test ERROR on linus/master]
[also build test ERROR on next-20161221]
[cannot apply to v4.9]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On Tue, Dec 20, 2016 at 11:44 PM, Andreas Schwab wrote:
> On Dez 20 2016, Geert Uytterhoeven wrote:
>> When I saw this patch, I was already a bit skeptical about it, but I noticed
>> other architectures (e.g. avr32) are doing the same, so I didn't
On Tue, Dec 20, 2016 at 11:44 PM, Andreas Schwab wrote:
> On Dez 20 2016, Geert Uytterhoeven wrote:
>> When I saw this patch, I was already a bit skeptical about it, but I noticed
>> other architectures (e.g. avr32) are doing the same, so I didn't reply.
>>
>> In my experience, "format '%zu'
Add a new feature which supports sending the page information
with range array. The current implementation uses PFNs array,
which is not very efficient. Using ranges can improve the
performance of inflating/deflating significantly.
Signed-off-by: Liang Li
Cc: Michael S.
Define the flags and head struct for a new host request virtual
queue. Guest can get requests from host and then responds to them on
this new virtual queue.
Host can make use of this virtual queue to request the guest do some
operations, e.g. drop page cache, synchronize file system, etc.
And the
Add a new feature which supports sending the page information
with range array. The current implementation uses PFNs array,
which is not very efficient. Using ranges can improve the
performance of inflating/deflating significantly.
Signed-off-by: Liang Li
Cc: Michael S. Tsirkin
Cc: Paolo
Define the flags and head struct for a new host request virtual
queue. Guest can get requests from host and then responds to them on
this new virtual queue.
Host can make use of this virtual queue to request the guest do some
operations, e.g. drop page cache, synchronize file system, etc.
And the
This patch contains two parts:
One is to add a new API to mm go get the unused page information.
The virtio balloon driver will use this new API added to get the
unused page info and send it to hypervisor(QEMU) to speed up live
migration. During sending the bitmap, some the pages may be modified
This patch contains two parts:
One is to add a new API to mm go get the unused page information.
The virtio balloon driver will use this new API added to get the
unused page info and send it to hypervisor(QEMU) to speed up live
migration. During sending the bitmap, some the pages may be modified
When doing the inflating/deflating operation, the current virtio-balloon
implementation uses an array to save 256 PFNS, then send these PFNS to
host through virtio and process each PFN one by one. This way is not
efficient when inflating/deflating a large mount of memory because too
many times of
When doing the inflating/deflating operation, the current virtio-balloon
implementation uses an array to save 256 PFNS, then send these PFNS to
host through virtio and process each PFN one by one. This way is not
efficient when inflating/deflating a large mount of memory because too
many times of
The implementation of the current virtio-balloon is not very
efficient, the time spends on different stages of inflating
the balloon to 7GB of a 8GB idle guest:
a. allocating pages (6.5%)
b. sending PFNs to host (68.3%)
c. address translation (6.1%)
d. madvise (19%)
It takes about 4126ms for the
This patch set contains two parts of changes to the virtio-balloon.
One is the change for speeding up the inflating & deflating process,
the main idea of this optimization is to use {pfn|length} to present
the page information instead of the PFNs, to reduce the overhead of
virtio data
The implementation of the current virtio-balloon is not very
efficient, the time spends on different stages of inflating
the balloon to 7GB of a 8GB idle guest:
a. allocating pages (6.5%)
b. sending PFNs to host (68.3%)
c. address translation (6.1%)
d. madvise (19%)
It takes about 4126ms for the
This patch set contains two parts of changes to the virtio-balloon.
One is the change for speeding up the inflating & deflating process,
the main idea of this optimization is to use {pfn|length} to present
the page information instead of the PFNs, to reduce the overhead of
virtio data
Hi Mathias,
I have some comments for the implementation of
xhci_handle_command_timeout() as well.
On 12/20/2016 11:13 PM, Mathias Nyman wrote:
> On 20.12.2016 09:30, Baolin Wang wrote:
> ...
>
> Alright, I gathered all current work related to xhci races and timeouts
> and put them into a branch:
Hi Mathias,
I have some comments for the implementation of
xhci_handle_command_timeout() as well.
On 12/20/2016 11:13 PM, Mathias Nyman wrote:
> On 20.12.2016 09:30, Baolin Wang wrote:
> ...
>
> Alright, I gathered all current work related to xhci races and timeouts
> and put them into a branch:
From: Fu Wei
The patch add memory-mapped timer register support by using the
information provided by the new GTDT driver of ACPI.
Signed-off-by: Fu Wei
---
drivers/clocksource/arm_arch_timer.c | 35 ---
1 file changed, 32
From: Fu Wei
This driver adds support for parsing SBSA Generic Watchdog timer
in GTDT, parse all info in SBSA Generic Watchdog Structure in GTDT,
and creating a platform device with that information.
This allows the operating system to obtain device data from the
resource of
From: Fu Wei
The patch add memory-mapped timer register support by using the
information provided by the new GTDT driver of ACPI.
Signed-off-by: Fu Wei
---
drivers/clocksource/arm_arch_timer.c | 35 ---
1 file changed, 32 insertions(+), 3 deletions(-)
diff
From: Fu Wei
This driver adds support for parsing SBSA Generic Watchdog timer
in GTDT, parse all info in SBSA Generic Watchdog Structure in GTDT,
and creating a platform device with that information.
This allows the operating system to obtain device data from the
resource of platform device.
From: Fu Wei
This patch adds support for parsing arch timer info in GTDT,
provides some kernel APIs to parse all the PPIs and
always-on info in GTDT and export them.
By this driver, we can simplify arm_arch_timer drivers, and
separate the ACPI GTDT knowledge from it.
From: Fu Wei
On platforms booting with ACPI, architected memory-mapped timers'
configuration data is provided by firmware through the ACPI GTDT
static table.
The clocksource architected timer kernel driver requires a firmware
interface to collect timer configuration and
From: Fu Wei
The patch update arm_arch_timer driver to use the function
provided by the new GTDT driver of ACPI.
By this way, arm_arch_timer.c can be simplified, and separate
all the ACPI GTDT knowledge from this timer driver.
Signed-off-by: Fu Wei
From: Fu Wei
The patch introduce two new structs: arch_timer_mem, arch_timer_mem_frame.
And also introduce a new define: ARCH_TIMER_MEM_MAX_FRAMES
These will be used for refactoring the memory-mapped timer init code to
prepare for GTDT
Signed-off-by: Fu Wei
From: Fu Wei
When system init with device-tree, we don't know which node will be
initialized first. And the code in arch_timer_common_init should wait
until per-cpu timer and MMIO timer are both initialized. So we need
arch_timer_needs_probing to detect the init status of
From: Fu Wei
The patch introduce two new structs: arch_timer_mem, arch_timer_mem_frame.
And also introduce a new define: ARCH_TIMER_MEM_MAX_FRAMES
These will be used for refactoring the memory-mapped timer init code to
prepare for GTDT
Signed-off-by: Fu Wei
---
From: Fu Wei
When system init with device-tree, we don't know which node will be
initialized first. And the code in arch_timer_common_init should wait
until per-cpu timer and MMIO timer are both initialized. So we need
arch_timer_needs_probing to detect the init status of system.
But currently
From: Fu Wei
The patch update arm_arch_timer driver to use the function
provided by the new GTDT driver of ACPI.
By this way, arm_arch_timer.c can be simplified, and separate
all the ACPI GTDT knowledge from this timer driver.
Signed-off-by: Fu Wei
Signed-off-by: Hanjun Guo
Tested-by:
From: Fu Wei
This patch adds support for parsing arch timer info in GTDT,
provides some kernel APIs to parse all the PPIs and
always-on info in GTDT and export them.
By this driver, we can simplify arm_arch_timer drivers, and
separate the ACPI GTDT knowledge from it.
Signed-off-by: Fu Wei
From: Fu Wei
On platforms booting with ACPI, architected memory-mapped timers'
configuration data is provided by firmware through the ACPI GTDT
static table.
The clocksource architected timer kernel driver requires a firmware
interface to collect timer configuration and configure its driver.
From: Fu Wei
Because arch_timer_needs_of_probing is only for booting with device-tree,
but arch_timer_common_init is a generic init call which shouldn't include
the FW-specific code. It's better to put arch_timer_needs_of_probing into
DT init function.
But for per-cpu timer,
From: Fu Wei
The patch refactor original memory-mapped timer init code:
(1) Refactor "arch_timer_mem_init", make it become a common code for
memory-mapped timer init.
(2) Add a new function "arch_timer_mem_of_init" for DT init.
Signed-off-by: Fu Wei
From: Fu Wei
The patch refactor original memory-mapped timer init code:
(1) Refactor "arch_timer_mem_init", make it become a common code for
memory-mapped timer init.
(2) Add a new function "arch_timer_mem_of_init" for DT init.
Signed-off-by: Fu Wei
---
From: Fu Wei
Because arch_timer_needs_of_probing is only for booting with device-tree,
but arch_timer_common_init is a generic init call which shouldn't include
the FW-specific code. It's better to put arch_timer_needs_of_probing into
DT init function.
But for per-cpu timer, the
From: Fu Wei
Rename some enums and defines, to unify the format of enums and defines
in arm_arch_timer.h, also update all the users of these enums and defines:
drivers/clocksource/arm_arch_timer.c
virt/kvm/arm/hyp/timer-sr.c
No functional change.
Signed-off-by: Fu
From: Fu Wei
Rename some enums and defines, to unify the format of enums and defines
in arm_arch_timer.h, also update all the users of these enums and defines:
drivers/clocksource/arm_arch_timer.c
virt/kvm/arm/hyp/timer-sr.c
No functional change.
Signed-off-by: Fu Wei
Tested-by:
From: Fu Wei
This patch defines pr_fmt(fmt) for all pr_* functions,
then the pr_* doesn't need to add "arch_timer:" everytime.
According to the suggestion from checkpatch.pl:
(1) delete some Blank Spaces in arch_timer_banner;
(2) delete a redundant Tab in a bland line of
From: Fu Wei
Currently, the arch timer driver uses ARCH_TIMER_PHYS_SECURE_PPI to
mean the driver will use the secure PPI *and* potentialy also use the
non-secure PPI. This is somewhat confusing.
For arm64, where it never makes sense to use the secure PPI, this
means we must
From: Fu Wei
Currently, the counter frequency detection call(arch_timer_detect_rate)
combines all the ways to get counter frequency: device-tree property,
system coprocessor register, MMIO timer. But in the most of use cases,
we don't need all the ways to try:
For example,
From: Fu Wei
To support the arm_arch_timer via ACPI we need to share defines and enums
between the driver and the ACPI parser code.
Split out the relevant defines and enums into arm_arch_timer.h, and
change "enum ppi_nr" to "enum arch_timer_ppi_nr" to avoid the potential
name
From: Fu Wei
This patch add a new enum "arch_timer_spi_nr" and use it in the driver.
Just for code's readability, no functional change.
Signed-off-by: Fu Wei
Acked-by: Mark Rutland
---
drivers/clocksource/arm_arch_timer.c | 4 ++--
From: Fu Wei
Currently, the counter frequency detection call(arch_timer_detect_rate)
combines all the ways to get counter frequency: device-tree property,
system coprocessor register, MMIO timer. But in the most of use cases,
we don't need all the ways to try:
For example, reading device-tree
From: Fu Wei
To support the arm_arch_timer via ACPI we need to share defines and enums
between the driver and the ACPI parser code.
Split out the relevant defines and enums into arm_arch_timer.h, and
change "enum ppi_nr" to "enum arch_timer_ppi_nr" to avoid the potential
name clashes.
Also
From: Fu Wei
This patch add a new enum "arch_timer_spi_nr" and use it in the driver.
Just for code's readability, no functional change.
Signed-off-by: Fu Wei
Acked-by: Mark Rutland
---
drivers/clocksource/arm_arch_timer.c | 4 ++--
include/clocksource/arm_arch_timer.h | 6 ++
2 files
From: Fu Wei
This patch defines pr_fmt(fmt) for all pr_* functions,
then the pr_* doesn't need to add "arch_timer:" everytime.
According to the suggestion from checkpatch.pl:
(1) delete some Blank Spaces in arch_timer_banner;
(2) delete a redundant Tab in a bland line of arch_timer_init(void)
From: Fu Wei
Currently, the arch timer driver uses ARCH_TIMER_PHYS_SECURE_PPI to
mean the driver will use the secure PPI *and* potentialy also use the
non-secure PPI. This is somewhat confusing.
For arm64, where it never makes sense to use the secure PPI, this
means we must always request the
From: Fu Wei
This patchset:
(1)Preparation for adding GTDT support in arm_arch_timer:
1. Move some enums and marcos to header file;
2. Add a new enum for spi type;
3. Improve printk relevant code;
4. Rename some enums and defines;
5.
From: Fu Wei
This patchset:
(1)Preparation for adding GTDT support in arm_arch_timer:
1. Move some enums and marcos to header file;
2. Add a new enum for spi type;
3. Improve printk relevant code;
4. Rename some enums and defines;
5. Rework PPI
1 - 100 of 1440 matches
Mail list logo