On Mon, Jun 06, 2016 at 02:55:29PM -0400, Jarod Wilson wrote:
> On Mon, Jun 06, 2016 at 05:29:30PM +0100, Bert Kenward wrote:
> > 7000-series SFC NICs connected with an SFP+ module currently fail to
> > report any supported link speeds.
> >
> > Reported-by: Jarod Wilson
> >
On Mon, Jun 06, 2016 at 02:55:29PM -0400, Jarod Wilson wrote:
> On Mon, Jun 06, 2016 at 05:29:30PM +0100, Bert Kenward wrote:
> > 7000-series SFC NICs connected with an SFP+ module currently fail to
> > report any supported link speeds.
> >
> > Reported-by: Jarod Wilson
> > Signed-off-by: Bert
alloc_workqueue replaces deprecated create_workqueue().
The workqueue device_reset_wq has workitem _data->reset_work per
adf_reset_dev_data. The workqueue pf2vf_resp_wq is a workqueue for
PF2VF responses has workitem _resp->pf2vf_resp_work per pf2vf_resp.
The workqueue adf_vf_stop_wq is used to
alloc_workqueue replaces deprecated create_workqueue().
The workqueue device_reset_wq has workitem _data->reset_work per
adf_reset_dev_data. The workqueue pf2vf_resp_wq is a workqueue for
PF2VF responses has workitem _resp->pf2vf_resp_work per pf2vf_resp.
The workqueue adf_vf_stop_wq is used to
On 6/7/16, 4:26 PM, "Mike Kravetz" wrote:
>The write at the end of the test to restore nr_hugepages to its previous
>value is failing. This is because it is trying to write the number of
>bytes in the char array as opposed to the number of bytes in the string.
>
On 6/7/16, 4:26 PM, "Mike Kravetz" wrote:
>The write at the end of the test to restore nr_hugepages to its previous
>value is failing. This is because it is trying to write the number of
>bytes in the char array as opposed to the number of bytes in the string.
>
>Signed-off-by: Mike Kravetz
On Tue, Jun 7, 2016 at 2:02 PM, Andy Grover wrote:
> On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote:
>>
>> Hi HCH & Co,
>>
>> On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote:
>>>
>>> This patch set adds a generic NVMe over Fabrics target. The
>>> implementation
On Tue, Jun 7, 2016 at 2:02 PM, Andy Grover wrote:
> On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote:
>>
>> Hi HCH & Co,
>>
>> On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote:
>>>
>>> This patch set adds a generic NVMe over Fabrics target. The
>>> implementation conforms to the
Managed to find someone in the office with one of these laptops and it looks
like the adaptive keyboard works perfectly with this patch, so I can give my t-
b:
Tested-by: Lyude Paul
Cheers,
Lyude
On Tue, 2016-06-07 at 13:02 -0400, Lyude Paul wrote:
> Since
Managed to find someone in the office with one of these laptops and it looks
like the adaptive keyboard works perfectly with this patch, so I can give my t-
b:
Tested-by: Lyude Paul
Cheers,
Lyude
On Tue, 2016-06-07 at 13:02 -0400, Lyude Paul wrote:
> Since nothing's really
Many users (and some applications) are expecting the CPU clock speed to
be output in /proc/cpuinfo (as is done in x86, avr32, c6x, tile, parisc,
ia64, and xtensa). This can be trivially added by simply querying the
clock described in the CPU node of the device tree. It appears that
many of the
Query the CPU core clock in the device tree to determine the core clock
speed. Output this clock rate in /proc/cpuinfo to match the output
from other architectures. The output is intentionally patterned after
the x86 output, to match existing (and possibly expected) convention.
If any errors
Query the CPU core clock in the device tree to determine the core clock
speed. Output this clock rate in /proc/cpuinfo to match the output
from other architectures. The output is intentionally patterned after
the x86 output, to match existing (and possibly expected) convention.
If any errors
Many users (and some applications) are expecting the CPU clock speed to
be output in /proc/cpuinfo (as is done in x86, avr32, c6x, tile, parisc,
ia64, and xtensa). This can be trivially added by simply querying the
clock described in the CPU node of the device tree. It appears that
many of the
Hi Magnus,
On Thu, Jun 2, 2016 at 5:55 PM, Magnus Damm wrote:
> iommu/ipmmu-vmsa: IPMMU multi-arch update V3
>
> [PATCH v3 01/06] iommu/ipmmu-vmsa: Remove platform data handling
> [PATCH v3 02/06] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for
> context
>
Hi Magnus,
On Thu, Jun 2, 2016 at 5:55 PM, Magnus Damm wrote:
> iommu/ipmmu-vmsa: IPMMU multi-arch update V3
>
> [PATCH v3 01/06] iommu/ipmmu-vmsa: Remove platform data handling
> [PATCH v3 02/06] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for
> context
> [PATCH v3 03/06]
On Tue, Jun 07, 2016 at 02:43:17PM -0500, Josh Poimboeuf wrote:
> @@ -403,9 +402,10 @@ DECLARE_EVENT_CLASS(sched_stat_runtime,
> (unsigned long long)__entry->vruntime)
> );
>
> -DEFINE_EVENT(sched_stat_runtime, sched_stat_runtime,
> - TP_PROTO(struct task_struct
On Tue, Jun 07, 2016 at 02:43:17PM -0500, Josh Poimboeuf wrote:
> @@ -403,9 +402,10 @@ DECLARE_EVENT_CLASS(sched_stat_runtime,
> (unsigned long long)__entry->vruntime)
> );
>
> -DEFINE_EVENT(sched_stat_runtime, sched_stat_runtime,
> - TP_PROTO(struct task_struct
On Tue, Jun 07, 2016 at 11:11:09AM -0700, Luck, Tony wrote:
> Is there a reason that we need to call the ce_add_elem() inline
> here instead of having it just register on the mce_notifier chain?
> This series just cleaned out all the /dev/mcelog special code from
> here, and you are adding
On Tue, Jun 07, 2016 at 11:11:09AM -0700, Luck, Tony wrote:
> Is there a reason that we need to call the ce_add_elem() inline
> here instead of having it just register on the mce_notifier chain?
> This series just cleaned out all the /dev/mcelog special code from
> here, and you are adding
On Tue, Jun 07, 2016 at 09:54:48PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 07, 2016 at 02:43:17PM -0500, Josh Poimboeuf wrote:
> > 1. Instead of just warning and allowing the tracepoints to be broken,
> >I'd argue that it would be better to make them work by forcing
> >schedstats
On Tue, Jun 07, 2016 at 09:54:48PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 07, 2016 at 02:43:17PM -0500, Josh Poimboeuf wrote:
> > 1. Instead of just warning and allowing the tracepoints to be broken,
> >I'd argue that it would be better to make them work by forcing
> >schedstats
On Jun 2, 2016, at 6:01 AM, Lin Feng wrote:
>
> Descriptions:
> ext4 block allocation core stack:
> ext4_mb_new_blocks
> ext4_mb_normalize_request
> ext4_mb_regular_allocator
>ext4_mb_find_by_goal
> mb_find_extent(e4b, ac->ac_g_ex.fe_start, ac->ac_g_ex.fe_len,
On Jun 2, 2016, at 6:01 AM, Lin Feng wrote:
>
> Descriptions:
> ext4 block allocation core stack:
> ext4_mb_new_blocks
> ext4_mb_normalize_request
> ext4_mb_regular_allocator
>ext4_mb_find_by_goal
> mb_find_extent(e4b, ac->ac_g_ex.fe_start, ac->ac_g_ex.fe_len, );
>
> The start block
On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote:
Hi HCH & Co,
On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote:
This patch set adds a generic NVMe over Fabrics target. The
implementation conforms to the NVMe 1.2b specification (which
includes Fabrics) and provides the NVMe over
On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote:
Hi HCH & Co,
On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote:
This patch set adds a generic NVMe over Fabrics target. The
implementation conforms to the NVMe 1.2b specification (which
includes Fabrics) and provides the NVMe over
+Mark R
On Fri, Jun 3, 2016 at 3:26 PM, Pantelis Antoniou
wrote:
> In certain cases it makes sense to create cascaded GPIO which
> are not real GPIOs, merely point to the real backend GPIO chip.
In what cases? Make it clear what this is for. Connectors of course,
+Mark R
On Fri, Jun 3, 2016 at 3:26 PM, Pantelis Antoniou
wrote:
> In certain cases it makes sense to create cascaded GPIO which
> are not real GPIOs, merely point to the real backend GPIO chip.
In what cases? Make it clear what this is for. Connectors of course,
but are there any other use
On Tue, Jun 7, 2016 at 1:58 PM, Michal Marek wrote:
> Dne 25.5.2016 v 19:12 Kees Cook napsal(a):
>> On Wed, May 25, 2016 at 3:46 AM, Michal Marek wrote:
>>> On 2016-05-24 19:04, Kees Cook wrote:
On Mon, May 23, 2016 at 3:07 PM, Emese Revfy
On Tue, Jun 7, 2016 at 1:58 PM, Michal Marek wrote:
> Dne 25.5.2016 v 19:12 Kees Cook napsal(a):
>> On Wed, May 25, 2016 at 3:46 AM, Michal Marek wrote:
>>> On 2016-05-24 19:04, Kees Cook wrote:
On Mon, May 23, 2016 at 3:07 PM, Emese Revfy wrote:
> This patch set introduce the GCC
Dne 25.5.2016 v 19:12 Kees Cook napsal(a):
> On Wed, May 25, 2016 at 3:46 AM, Michal Marek wrote:
>> On 2016-05-24 19:04, Kees Cook wrote:
>>> On Mon, May 23, 2016 at 3:07 PM, Emese Revfy wrote:
This patch set introduce the GCC plugin infrastructure with
Dne 25.5.2016 v 19:12 Kees Cook napsal(a):
> On Wed, May 25, 2016 at 3:46 AM, Michal Marek wrote:
>> On 2016-05-24 19:04, Kees Cook wrote:
>>> On Mon, May 23, 2016 at 3:07 PM, Emese Revfy wrote:
This patch set introduce the GCC plugin infrastructure with examples for
testing
and
In that case, any users of early_panic() end up calling panic().
Signed-off-by: Chris Metcalf
---
I don't think this is a recent breakage, and it doesn't feel too
critical, so I'll just push it in the next merge window.
arch/tile/include/asm/setup.h | 5 +
1 file
In that case, any users of early_panic() end up calling panic().
Signed-off-by: Chris Metcalf
---
I don't think this is a recent breakage, and it doesn't feel too
critical, so I'll just push it in the next merge window.
arch/tile/include/asm/setup.h | 5 +
1 file changed, 5 insertions(+)
Vinod Koul writes:
> On Mon, Jun 06, 2016 at 11:10:38PM -0700, Eric Anholt wrote:
>> >> >> - if (ret == DMA_COMPLETE || !txstate)
>> >> >> + if (ret == DMA_COMPLETE)
>> >> >
>> >> > Why do you change this? txstate can be NULL, so no point calculating
>> >> >
Vinod Koul writes:
> On Mon, Jun 06, 2016 at 11:10:38PM -0700, Eric Anholt wrote:
>> >> >> - if (ret == DMA_COMPLETE || !txstate)
>> >> >> + if (ret == DMA_COMPLETE)
>> >> >
>> >> > Why do you change this? txstate can be NULL, so no point calculating
>> >> > reside
>> >> > for those
On Fri, Jun 03, 2016 at 02:50:49PM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> These are the remaining 2 patches from the AXP809 series.
>
> Changes since v2:
>
> - Drop sunxi-common-regulators.dtsi instead of disabling dummy regulators.
Applied both, thanks!
Maxime
--
Maxime Ripard, Free
From: Dave Hansen
Today, mprotect() takes 4 bits of data: PROT_READ/WRITE/EXEC/NONE.
Three of those bits: READ/WRITE/EXEC get translated directly in to
vma->vm_flags by calc_vm_prot_bits(). If a bit is unset in
mprotect()'s 'prot' argument then it must be cleared
On Fri, Jun 03, 2016 at 02:50:49PM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> These are the remaining 2 patches from the AXP809 series.
>
> Changes since v2:
>
> - Drop sunxi-common-regulators.dtsi instead of disabling dummy regulators.
Applied both, thanks!
Maxime
--
Maxime Ripard, Free
From: Dave Hansen
Today, mprotect() takes 4 bits of data: PROT_READ/WRITE/EXEC/NONE.
Three of those bits: READ/WRITE/EXEC get translated directly in to
vma->vm_flags by calc_vm_prot_bits(). If a bit is unset in
mprotect()'s 'prot' argument then it must be cleared in vma->vm_flags
during the
From: Dave Hansen
This is all that we need to get the new system call itself
working on x86.
Signed-off-by: Dave Hansen
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Cc: x...@kernel.org
Cc: torva...@linux-foundation.org
Cc:
From: Dave Hansen
This is all that we need to get the new system call itself
working on x86.
Signed-off-by: Dave Hansen
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Cc: x...@kernel.org
Cc: torva...@linux-foundation.org
Cc: a...@linux-foundation.org
---
From: Dave Hansen
pkey_mprotect() is just like mprotect, except it also takes a
protection key as an argument. On systems that do not support
protection keys, it still works, but requires that key=0.
Otherwise it does exactly what mprotect does.
I expect it to get
From: Dave Hansen
pkey_mprotect() is just like mprotect, except it also takes a
protection key as an argument. On systems that do not support
protection keys, it still works, but requires that key=0.
Otherwise it does exactly what mprotect does.
I expect it to get used like this, if you want
From: Dave Hansen
PF_PK means that a memory access violated the protection key
access restrictions. It is unconditionally an access_error()
because the permissions set on the VMA don't matter (the PKRU
value overrides it), and we never "resolve" PK faults (like
how
From: Dave Hansen
PF_PK means that a memory access violated the protection key
access restrictions. It is unconditionally an access_error()
because the permissions set on the VMA don't matter (the PKRU
value overrides it), and we never "resolve" PK faults (like
how a COW can "resolve write
From: Dave Hansen
This patch adds two new system calls:
int pkey_alloc(unsigned long flags, unsigned long init_access_rights)
int pkey_free(int pkey);
These implement an "allocator" for the protection keys
themselves, which can be thought of as
From: Dave Hansen
This establishes two more system calls for protection key management:
unsigned long pkey_get(int pkey);
int pkey_set(int pkey, unsigned long access_rights);
The return value from pkey_get() and the 'access_rights' passed
to
From: Dave Hansen
This establishes two more system calls for protection key management:
unsigned long pkey_get(int pkey);
int pkey_set(int pkey, unsigned long access_rights);
The return value from pkey_get() and the 'access_rights' passed
to pkey_set() are the same format: a
From: Dave Hansen
This patch adds two new system calls:
int pkey_alloc(unsigned long flags, unsigned long init_access_rights)
int pkey_free(int pkey);
These implement an "allocator" for the protection keys
themselves, which can be thought of as analogous to the allocator
that
From: Dave Hansen
These new syscalls are implemented as generic code, so enable
them for architectures like arm64 which use the generic syscall
table.
According to Arnd:
Even if the support is x86 specific for the forseeable
future, it may be good
From: Dave Hansen
These new syscalls are implemented as generic code, so enable
them for architectures like arm64 which use the generic syscall
table.
According to Arnd:
Even if the support is x86 specific for the forseeable
future, it may be good to reserve the number just in
From: Dave Hansen
This code should be a good demonstration of how to use the new
system calls as well as how to use protection keys in general.
This code shows how to:
1. Manipulate the Protection Keys Rights User (PKRU) register with
sys_pkey_get/set()
2. Set a
From: Dave Hansen
This code should be a good demonstration of how to use the new
system calls as well as how to use protection keys in general.
This code shows how to:
1. Manipulate the Protection Keys Rights User (PKRU) register with
sys_pkey_get/set()
2. Set a protection key on memory
3.
Are there any concerns with merging these into the x86 tree so
that they go upstream for 4.8? The updates here are pretty
minor.
Changes from v1:
* updates to alloc/free patch description calling out that
"in-use" pkeys may still be pkey_free()'d successfully.
* Fixed a bug in the selftest
From: Dave Hansen
This spells out all of the pkey-related system calls that we have
and provides some example code fragments to demonstrate how we
expect them to be used.
Signed-off-by: Dave Hansen
Cc: linux-...@vger.kernel.org
Cc:
Are there any concerns with merging these into the x86 tree so
that they go upstream for 4.8? The updates here are pretty
minor.
Changes from v1:
* updates to alloc/free patch description calling out that
"in-use" pkeys may still be pkey_free()'d successfully.
* Fixed a bug in the selftest
From: Dave Hansen
This spells out all of the pkey-related system calls that we have
and provides some example code fragments to demonstrate how we
expect them to be used.
Signed-off-by: Dave Hansen
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Cc: x...@kernel.org
Cc:
Some clocks in the Allwinner SoCs clocks unit are just simple gates. Add
support for those clocks.
Since it's a feature that can also be found in more complex clocks, provide
a bunch of helpers that can be reused later on.
Signed-off-by: Maxime Ripard
---
Hi,
This is an attempt at introducing clock support for the Allwinner SoCs
following the current model used by pretty much all the other SoCs.
Such a conversion has been suggested on a regular basis by Mike and
Stephen, and here is a first implementation.
This new approach has a good number of
Some clocks in the Allwinner SoCs clocks unit are just simple gates. Add
support for those clocks.
Since it's a feature that can also be found in more complex clocks, provide
a bunch of helpers that can be reused later on.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/Makefile | 1 +
Hi,
This is an attempt at introducing clock support for the Allwinner SoCs
following the current model used by pretty much all the other SoCs.
Such a conversion has been suggested on a regular basis by Mike and
Stephen, and here is a first implementation.
This new approach has a good number of
Some clocks can be switched to a mode called fractional that have two fixed
output rate you can choose from.
Add a small library to deal with those clocks.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/Makefile | 2 +
Some clocks can be switched to a mode called fractional that have two fixed
output rate you can choose from.
Add a small library to deal with those clocks.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/Makefile | 2 +
drivers/clk/sunxi-ng/ccu_frac.c | 110
Some clocks in the Allwinner SoCs clock units are direct, fixed,
multipliers or dividers from their parent.
Add support for such clocks.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/Makefile | 2 ++
drivers/clk/sunxi-ng/ccu_fixed_factor.c |
Some clocks in the Allwinner SoCs clock units are direct, fixed,
multipliers or dividers from their parent.
Add support for such clocks.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/Makefile | 2 ++
drivers/clk/sunxi-ng/ccu_fixed_factor.c | 50
Start our new clock infrastructure by adding the registration code, common
structure and common code.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Moved from of_iomap to of_io_request_and_map
- Change lock bit feature name to PLL_LOCK
- Fixed bug
Start our new clock infrastructure by adding the registration code, common
structure and common code.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Moved from of_iomap to of_io_request_and_map
- Change lock bit feature name to PLL_LOCK
- Fixed bug in clocks description array
Add the list of clocks and resets found in the H3 CCU.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Only build the H3 clocks description when MACH_SUN8I is set
---
drivers/clk/sunxi-ng/Makefile| 2 +
drivers/clk/sunxi-ng/ccu-sun8i-h3.c |
Add the list of clocks and resets found in the H3 CCU.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Only build the H3 clocks description when MACH_SUN8I is set
---
drivers/clk/sunxi-ng/Makefile| 2 +
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 703
Now that we have a different clock representation, switch to it.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-h3.dtsi | 312
1 file changed, 60 insertions(+), 252 deletions(-)
diff --git
Now that we have a different clock representation, switch to it.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-h3.dtsi | 312
1 file changed, 60 insertions(+), 252 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
On Thu, Jun 02, 2016 at 03:50:11PM +0800, Chen-Yu Tsai wrote:
> The BPI-M2+ is an H3 development board. It is a smaller form factor than
> the original BPI-M2, with the new H3 SoC.
>
> It has 1GB DRAM, 8GB eMMC, a micro SD card slot, HDMI output, 2 USB
> host connector and 1 USB OTG connector, an
Introduce support for clocks that use a combination of two linear
multipliers.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu_nk.c | 147 ++
drivers/clk/sunxi-ng/ccu_nk.h
Introduce support for clocks that multiply and divide using linear factors.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Fixed the maximums for both factors passed to the rational factor
computation.
---
drivers/clk/sunxi-ng/Makefile | 1 +
Introduce support for clocks that use a combination of two linear
multipliers.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu_nk.c | 147 ++
drivers/clk/sunxi-ng/ccu_nk.h | 73 +
3
Introduce support for clocks that multiply and divide using linear factors.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Fixed the maximums for both factors passed to the rational factor
computation.
---
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu_nm.c | 114
On Thu, Jun 02, 2016 at 03:50:11PM +0800, Chen-Yu Tsai wrote:
> The BPI-M2+ is an H3 development board. It is a smaller form factor than
> the original BPI-M2, with the new H3 SoC.
>
> It has 1GB DRAM, 8GB eMMC, a micro SD card slot, HDMI output, 2 USB
> host connector and 1 USB OTG connector, an
Some clocks in the Allwinner SoCs clocks unit are just muxes.
However, those muxes might also be found in some other complicated clocks
that would benefit from the code in there to deal with "advanced" features,
like pre-dividers.
Introduce a set of helpers to reduce the code duplication in such
Introduce support for clocks that use a combination of two linear
multipliers (N and K factors), one linear divider (M) and one power of two
divider (P).
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Declared our find_best function static
- Fixed our
Add support for the various dividers (linear, table or pow-of-two based)
found in the CCU.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu_div.c | 136 +
Add support for the clocks in the CCU that introduce a phase shift from
their parent clock.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/Makefile| 1 +
drivers/clk/sunxi-ng/ccu_phase.c | 126 +++
Some clocks in the Allwinner SoCs clocks unit are just muxes.
However, those muxes might also be found in some other complicated clocks
that would benefit from the code in there to deal with "advanced" features,
like pre-dividers.
Introduce a set of helpers to reduce the code duplication in such
Introduce support for clocks that use a combination of two linear
multipliers (N and K factors), one linear divider (M) and one power of two
divider (P).
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Declared our find_best function static
- Fixed our set_rate function that was always
Add support for the various dividers (linear, table or pow-of-two based)
found in the CCU.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu_div.c | 136 +
drivers/clk/sunxi-ng/ccu_div.h | 135
Add support for the clocks in the CCU that introduce a phase shift from
their parent clock.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/Makefile| 1 +
drivers/clk/sunxi-ng/ccu_phase.c | 126 +++
drivers/clk/sunxi-ng/ccu_phase.h | 50
Introduce support for the clocks that combine a linear divider and a
power-of-two based one.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu_mp.c | 158 ++
On Tue, 2016-06-07 at 17:21 +0900, Minchan Kim wrote:
> On Wed, Jun 01, 2016 at 11:23:53AM -0700, Tim Chen wrote:
> >
> > On Wed, 2016-06-01 at 16:12 +0900, Minchan Kim wrote:
> > >
> > >
> > > Hi Tim,
> > >
> > > To me, this reorganization is too limited and not good for me,
> > > frankly
Introduce support for the clocks that combine a linear divider and a
power-of-two based one.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu_mp.c | 158 ++
drivers/clk/sunxi-ng/ccu_mp.h | 78
On Tue, 2016-06-07 at 17:21 +0900, Minchan Kim wrote:
> On Wed, Jun 01, 2016 at 11:23:53AM -0700, Tim Chen wrote:
> >
> > On Wed, 2016-06-01 at 16:12 +0900, Minchan Kim wrote:
> > >
> > >
> > > Hi Tim,
> > >
> > > To me, this reorganization is too limited and not good for me,
> > > frankly
Introduce a new binding with its documentation for the brand new clock
sub-framework.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644
Introduce a new binding with its documentation for the brand new clock
sub-framework.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644
Introduce support for clocks that multiply and divide using two linear
multipliers and one linear divider.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Declared the find_best function static
- Fixed the set_rate function that was always writing the
Introduce support for clocks that multiply and divide using two linear
multipliers and one linear divider.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Declared the find_best function static
- Fixed the set_rate function that was always writing the various factors
at the same
On Tue, Jun 7, 2016 at 3:08 AM, Zhen Lei wrote:
> v3 -> v4:
> 1. Packed three patches of Kefeng Wang, patch6-8.
> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
>
> v2 -> v3:
> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make
> the
On Tue, Jun 7, 2016 at 3:08 AM, Zhen Lei wrote:
> v3 -> v4:
> 1. Packed three patches of Kefeng Wang, patch6-8.
> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
>
> v2 -> v3:
> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make
> the
>patches looks more
On Tue, Jun 07, 2016 at 08:38:42PM +0300, Vladimir Zapolskiy wrote:
> From: Robin Gong
>
> Add set_pretimeout since our watchdog driver has those interfaces and
> obviously, the new common watchdog framework didn't implement this
> interface.
>
> Signed-off-by: Robin Gong
On Tue, Jun 07, 2016 at 08:38:42PM +0300, Vladimir Zapolskiy wrote:
> From: Robin Gong
>
> Add set_pretimeout since our watchdog driver has those interfaces and
> obviously, the new common watchdog framework didn't implement this
> interface.
>
> Signed-off-by: Robin Gong
> [vzapolskiy:
Hi,
On 6/7/2016 12:33 PM, Bhaktipriya Shridhar wrote:
alloc_workqueue replaces deprecated create_workqueue().
Since the driver is infiniband which can be used as block device and the
workqueue seems involved in regular operation of the device, so a
dedicated workqueue has been used with
Hi,
On 6/7/2016 12:33 PM, Bhaktipriya Shridhar wrote:
alloc_workqueue replaces deprecated create_workqueue().
Since the driver is infiniband which can be used as block device and the
workqueue seems involved in regular operation of the device, so a
dedicated workqueue has been used with
501 - 600 of 2408 matches
Mail list logo