On Mon, Oct 15, 2018 at 09:44:41PM +0200, Niklas Cassel wrote:
> QCOM_QMI_HELPERS is a hidden kconfig, so the proper usage is
> to select it, not depend upon it.
>
> Because of this change, we now also need to depend on the same
> Kconfigs as QCOM_QMI_HELPERS depends on.
>
> Signed-off-by:
On Mon, Oct 15, 2018 at 09:44:41PM +0200, Niklas Cassel wrote:
> QCOM_QMI_HELPERS is a hidden kconfig, so the proper usage is
> to select it, not depend upon it.
>
> Because of this change, we now also need to depend on the same
> Kconfigs as QCOM_QMI_HELPERS depends on.
>
> Signed-off-by:
On Wed, Nov 07, 2018 at 01:50:39PM +, Patrick Bellasi wrote:
> On 07-Nov 13:11, Peter Zijlstra wrote:
> > On Mon, Oct 29, 2018 at 06:32:56PM +, Patrick Bellasi wrote:
> >
> > > @@ -50,11 +52,13 @@
> > > #define SCHED_FLAG_RESET_ON_FORK 0x01
> > > #define SCHED_FLAG_RECLAIM
On Wed, Nov 07, 2018 at 01:50:39PM +, Patrick Bellasi wrote:
> On 07-Nov 13:11, Peter Zijlstra wrote:
> > On Mon, Oct 29, 2018 at 06:32:56PM +, Patrick Bellasi wrote:
> >
> > > @@ -50,11 +52,13 @@
> > > #define SCHED_FLAG_RESET_ON_FORK 0x01
> > > #define SCHED_FLAG_RECLAIM
On 07-Nov 14:16, Peter Zijlstra wrote:
> On Mon, Oct 29, 2018 at 06:32:57PM +, Patrick Bellasi wrote:
>
> > +static void uclamp_group_put(unsigned int clamp_id, unsigned int group_id)
> > {
> > + union uclamp_map *uc_maps = _maps[clamp_id][0];
> > + union uclamp_map uc_map_old,
On 07-Nov 14:16, Peter Zijlstra wrote:
> On Mon, Oct 29, 2018 at 06:32:57PM +, Patrick Bellasi wrote:
>
> > +static void uclamp_group_put(unsigned int clamp_id, unsigned int group_id)
> > {
> > + union uclamp_map *uc_maps = _maps[clamp_id][0];
> > + union uclamp_map uc_map_old,
Enable PCI suspend/resume support on imx6sx socs. This is similar to
imx7d with a few differences:
* The PM_Turn_Off bit is exposed through an IOMUX GPR, like all other
pcie control bits on 6sx.
* The pcie_inbound_axi clk needs to be turned off in suspend. On resume
it is restored via resume ->
Enable PCI suspend/resume support on imx6sx socs. This is similar to
imx7d with a few differences:
* The PM_Turn_Off bit is exposed through an IOMUX GPR, like all other
pcie control bits on 6sx.
* The pcie_inbound_axi clk needs to be turned off in suspend. On resume
it is restored via resume ->
On Tue, Nov 6, 2018 at 10:31 AM, Kirill Tkhai wrote:
> When queue_interrupt() is called from fuse_dev_do_write(),
> it came from userspace directly. Userspace may pass any
> request id, even the request's we have not interrupted
> (or even background's request). This patch adds sanity
> check to
On Tue, Nov 6, 2018 at 10:31 AM, Kirill Tkhai wrote:
> When queue_interrupt() is called from fuse_dev_do_write(),
> it came from userspace directly. Userspace may pass any
> request id, even the request's we have not interrupted
> (or even background's request). This patch adds sanity
> check to
On 07-Nov 13:11, Peter Zijlstra wrote:
> On Mon, Oct 29, 2018 at 06:32:56PM +, Patrick Bellasi wrote:
>
> > @@ -50,11 +52,13 @@
> > #define SCHED_FLAG_RESET_ON_FORK 0x01
> > #define SCHED_FLAG_RECLAIM 0x02
> > #define SCHED_FLAG_DL_OVERRUN 0x04
> > -#define
On 07-Nov 13:11, Peter Zijlstra wrote:
> On Mon, Oct 29, 2018 at 06:32:56PM +, Patrick Bellasi wrote:
>
> > @@ -50,11 +52,13 @@
> > #define SCHED_FLAG_RESET_ON_FORK 0x01
> > #define SCHED_FLAG_RECLAIM 0x02
> > #define SCHED_FLAG_DL_OVERRUN 0x04
> > -#define
On Wed 31-10-18 22:13:00, Vasily Averin wrote:
> Fixes 3f2571c1f91f ("ext4: factor out xattr moving")
> cc: Jan Kara
> however issue was present in original ext4_expand_extra_isize_ea()
> Fixes 6dd4ee7cab7e ("ext4: Expand extra_inodes space per ...") # 2.6.23
> cc: Kalpak Shah
>
>
On Wed 31-10-18 22:13:00, Vasily Averin wrote:
> Fixes 3f2571c1f91f ("ext4: factor out xattr moving")
> cc: Jan Kara
> however issue was present in original ext4_expand_extra_isize_ea()
> Fixes 6dd4ee7cab7e ("ext4: Expand extra_inodes space per ...") # 2.6.23
> cc: Kalpak Shah
>
>
Signed-off-by: Geert Uytterhoeven
---
arch/microblaze/include/asm/pgtable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/microblaze/include/asm/pgtable.h
b/arch/microblaze/include/asm/pgtable.h
index f64ebb9c9a413535..bdfb2b3182b04c3b 100644
---
Signed-off-by: Geert Uytterhoeven
---
arch/microblaze/include/asm/pgtable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/microblaze/include/asm/pgtable.h
b/arch/microblaze/include/asm/pgtable.h
index f64ebb9c9a413535..bdfb2b3182b04c3b 100644
---
This patch Modify GPIO direction setting in pin configuration function.
please refer patch:
Kun Yi https://patchwork.ozlabs.org/patch/985540/
Tomer Maimon (1):
pinctrl: nuvoton: modify NPCM7xx pin configuration function
drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c | 13 +++--
1 file
- Spelling s/brigntess/brightness/,
- Double "use".
Signed-off-by: Geert Uytterhoeven
---
Documentation/ABI/testing/sysfs-class-led-trigger-pattern | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
Modify GPIO direction setting in pin configuration function by using
generic GPIO functions to set the GPIO direction instead of direct
access to the GPIO direction register.
Signed-off-by: Tomer Maimon
---
drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c | 13 +++--
1 file changed, 3
This patch Modify GPIO direction setting in pin configuration function.
please refer patch:
Kun Yi https://patchwork.ozlabs.org/patch/985540/
Tomer Maimon (1):
pinctrl: nuvoton: modify NPCM7xx pin configuration function
drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c | 13 +++--
1 file
- Spelling s/brigntess/brightness/,
- Double "use".
Signed-off-by: Geert Uytterhoeven
---
Documentation/ABI/testing/sysfs-class-led-trigger-pattern | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
Modify GPIO direction setting in pin configuration function by using
generic GPIO functions to set the GPIO direction instead of direct
access to the GPIO direction register.
Signed-off-by: Tomer Maimon
---
drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c | 13 +++--
1 file changed, 3
On Mon, Oct 29, 2018 at 06:32:57PM +, Patrick Bellasi wrote:
> +/**
> + * uclamp_group_get: increase the reference count for a clamp group
> + * @uc_se: the utilization clamp data for the task
> + * @clamp_id: the clamp index affected by the task
> + * @clamp_value: the new clamp value for the
On Mon, Oct 29, 2018 at 06:32:57PM +, Patrick Bellasi wrote:
> +/**
> + * uclamp_group_get: increase the reference count for a clamp group
> + * @uc_se: the utilization clamp data for the task
> + * @clamp_id: the clamp index affected by the task
> + * @clamp_value: the new clamp value for the
On Fri 2018-11-02 22:31:55, Tetsuo Handa wrote:
> Sometimes we want to print a whole line without being disturbed by
> concurrent printk() from interrupts and/or other threads, for printk()
> which does not end with '\n' can be disturbed.
>
> Since mixed printk() output makes it hard to
On Fri 2018-11-02 22:31:55, Tetsuo Handa wrote:
> Sometimes we want to print a whole line without being disturbed by
> concurrent printk() from interrupts and/or other threads, for printk()
> which does not end with '\n' can be disturbed.
>
> Since mixed printk() output makes it hard to
BD71837 and BD71847 have a HW functionality which leave power
rails OFF after powerof state:
- if they have been controlled by SW.
- if state transition from poweroff is done to SNVS
BD71837 can after reset transition from power-off to SNVS or
READY state depending on reset reason. By default
BD71837 and BD71847 have a HW functionality which leave power
rails OFF after powerof state:
- if they have been controlled by SW.
- if state transition from poweroff is done to SNVS
BD71837 can after reset transition from power-off to SNVS or
READY state depending on reset reason. By default
On 07/11/2018 13:58, Liran Alon wrote:
>
>
>> On 7 Nov 2018, at 14:47, Paolo Bonzini wrote:
>>
>> On 07/11/2018 13:10, Alexander Potapenko wrote:
>>> This appears to be a real bug in KVM.
>>> Please see a simplified reproducer attached.
>>
>> Thanks, I agree it's a reael bug. The basic issue
On 07/11/2018 13:58, Liran Alon wrote:
>
>
>> On 7 Nov 2018, at 14:47, Paolo Bonzini wrote:
>>
>> On 07/11/2018 13:10, Alexander Potapenko wrote:
>>> This appears to be a real bug in KVM.
>>> Please see a simplified reproducer attached.
>>
>> Thanks, I agree it's a reael bug. The basic issue
On Mon, Oct 29, 2018 at 06:32:57PM +, Patrick Bellasi wrote:
> +/**
> + * uclamp_group_get: increase the reference count for a clamp group
> + * @uc_se: the utilization clamp data for the task
> + * @clamp_id: the clamp index affected by the task
> + * @clamp_value: the new clamp value for the
On Mon, Oct 29, 2018 at 06:32:57PM +, Patrick Bellasi wrote:
> +/**
> + * uclamp_group_get: increase the reference count for a clamp group
> + * @uc_se: the utilization clamp data for the task
> + * @clamp_id: the clamp index affected by the task
> + * @clamp_value: the new clamp value for the
Hi Uwe,
On 7.11.2018 10:33, Uwe Kleine-König wrote:
> Hello Michal,
>
> just to state it more explicitly, I think the following patch (not even
> compile tested) is much preferable over your approach:
Interesting idea. I just wonder why nobody else did not come up with such
a simple solution
Hi Uwe,
On 7.11.2018 10:33, Uwe Kleine-König wrote:
> Hello Michal,
>
> just to state it more explicitly, I think the following patch (not even
> compile tested) is much preferable over your approach:
Interesting idea. I just wonder why nobody else did not come up with such
a simple solution
On Mon, Oct 29, 2018 at 06:32:57PM +, Patrick Bellasi wrote:
> +static void uclamp_group_put(unsigned int clamp_id, unsigned int group_id)
> {
> + union uclamp_map *uc_maps = _maps[clamp_id][0];
> + union uclamp_map uc_map_old, uc_map_new;
> + long res;
> +
> +retry:
> +
> +
On Tue, Nov 6, 2018 at 10:30 AM, Kirill Tkhai wrote:
> It's not possible to have answer to a request,
> before the request is actually sent. Add sanity
> check for that.
It's checking for the impossible. That sometimes makes sense as a
WARN_ON() or in special cases a BUG_ON().
>
>
On Mon, Oct 29, 2018 at 06:32:57PM +, Patrick Bellasi wrote:
> +static void uclamp_group_put(unsigned int clamp_id, unsigned int group_id)
> {
> + union uclamp_map *uc_maps = _maps[clamp_id][0];
> + union uclamp_map uc_map_old, uc_map_new;
> + long res;
> +
> +retry:
> +
> +
On Tue, Nov 6, 2018 at 10:30 AM, Kirill Tkhai wrote:
> It's not possible to have answer to a request,
> before the request is actually sent. Add sanity
> check for that.
It's checking for the impossible. That sometimes makes sense as a
WARN_ON() or in special cases a BUG_ON().
>
>
On Tue, Nov 6, 2018 at 10:30 AM, Kirill Tkhai wrote:
> We take global fiq->waitq.lock every time, when we are
> in this function, but interrupted requests are just small
> subset of all requests. This patch optimizes request_end()
> and makes it to take the lock when it's really needed.
>
>
On Tue, Nov 6, 2018 at 10:30 AM, Kirill Tkhai wrote:
> We take global fiq->waitq.lock every time, when we are
> in this function, but interrupted requests are just small
> subset of all requests. This patch optimizes request_end()
> and makes it to take the lock when it's really needed.
>
>
On Wed 07-11-18 23:53:24, Balbir Singh wrote:
> On Wed, Nov 07, 2018 at 08:35:48AM +0100, Michal Hocko wrote:
> > On Wed 07-11-18 07:35:18, Balbir Singh wrote:
[...]
> > > The check seems to be quite aggressive and in a loop that iterates
> > > pages, but has nothing to do with the page, did you
On Wed 07-11-18 23:53:24, Balbir Singh wrote:
> On Wed, Nov 07, 2018 at 08:35:48AM +0100, Michal Hocko wrote:
> > On Wed 07-11-18 07:35:18, Balbir Singh wrote:
[...]
> > > The check seems to be quite aggressive and in a loop that iterates
> > > pages, but has nothing to do with the page, did you
On Wed, Nov 07, 2018 at 11:52:31AM +0100, Daniel Lezcano wrote:
> > @@ -146,11 +152,38 @@ static void irqs_update(struct irqt_stat *irqs, u64
> > ts)
> > */
> > diff = interval - irqs->avg;
> >
> > + /*
> > +* Online average algorithm:
> > +*
> > +* new_average = average
On Wed, Nov 07, 2018 at 11:52:31AM +0100, Daniel Lezcano wrote:
> > @@ -146,11 +152,38 @@ static void irqs_update(struct irqt_stat *irqs, u64
> > ts)
> > */
> > diff = interval - irqs->avg;
> >
> > + /*
> > +* Online average algorithm:
> > +*
> > +* new_average = average
Hi Roy,
On 30.10.2018 22:30, Roy Pledge wrote:
> Starting with v5 of NXP QBMan devices the hardware supports using
> regular cacheable/shareable memory as the backing store for the
> portals.
>
> This patch adds support for the new portal mode by switching to
> use the DPRC get object region v2
Hi Roy,
On 30.10.2018 22:30, Roy Pledge wrote:
> Starting with v5 of NXP QBMan devices the hardware supports using
> regular cacheable/shareable memory as the backing store for the
> portals.
>
> This patch adds support for the new portal mode by switching to
> use the DPRC get object region v2
> On 7 Nov 2018, at 14:47, Paolo Bonzini wrote:
>
> On 07/11/2018 13:10, Alexander Potapenko wrote:
>> This appears to be a real bug in KVM.
>> Please see a simplified reproducer attached.
>
> Thanks, I agree it's a reael bug. The basic issue is that the
> kvm_state->size member is too
> On 7 Nov 2018, at 14:47, Paolo Bonzini wrote:
>
> On 07/11/2018 13:10, Alexander Potapenko wrote:
>> This appears to be a real bug in KVM.
>> Please see a simplified reproducer attached.
>
> Thanks, I agree it's a reael bug. The basic issue is that the
> kvm_state->size member is too
On Wed, 7 Nov 2018 at 11:47, Dietmar Eggemann wrote:
>
> On 11/5/18 10:10 AM, Vincent Guittot wrote:
> > On Fri, 2 Nov 2018 at 16:36, Dietmar Eggemann
> > wrote:
> >>
> >> On 10/26/18 6:11 PM, Vincent Guittot wrote:
>
> [...]
>
> >> Thinking about this new approach on a big.LITTLE platform:
>
On Wed, 7 Nov 2018 at 11:47, Dietmar Eggemann wrote:
>
> On 11/5/18 10:10 AM, Vincent Guittot wrote:
> > On Fri, 2 Nov 2018 at 16:36, Dietmar Eggemann
> > wrote:
> >>
> >> On 10/26/18 6:11 PM, Vincent Guittot wrote:
>
> [...]
>
> >> Thinking about this new approach on a big.LITTLE platform:
>
On 2018/11/07 19:21, Petr Mladek wrote:
> On Tue 2018-11-06 23:35:02, Sergey Senozhatsky wrote:
>>> Since we want to remove "struct cont" eventually, we will try to remove
>>> both "implicit printk() users who are expecting KERN_CONT behavior" and
>>> "explicit pr_cont()/printk(KERN_CONT) users".
On 2018/11/07 19:21, Petr Mladek wrote:
> On Tue 2018-11-06 23:35:02, Sergey Senozhatsky wrote:
>>> Since we want to remove "struct cont" eventually, we will try to remove
>>> both "implicit printk() users who are expecting KERN_CONT behavior" and
>>> "explicit pr_cont()/printk(KERN_CONT) users".
On Wed, Nov 07, 2018 at 08:35:48AM +0100, Michal Hocko wrote:
> On Wed 07-11-18 07:35:18, Balbir Singh wrote:
> > On Tue, Nov 06, 2018 at 10:55:24AM +0100, Michal Hocko wrote:
> > > From: Michal Hocko
> > >
> > > Page state checks are racy. Under a heavy memory workload (e.g. stress
> > > -m 200
On Wed, Nov 07, 2018 at 08:35:48AM +0100, Michal Hocko wrote:
> On Wed 07-11-18 07:35:18, Balbir Singh wrote:
> > On Tue, Nov 06, 2018 at 10:55:24AM +0100, Michal Hocko wrote:
> > > From: Michal Hocko
> > >
> > > Page state checks are racy. Under a heavy memory workload (e.g. stress
> > > -m 200
> On 7 Nov 2018, at 14:10, Alexander Potapenko wrote:
>
> On Wed, Nov 7, 2018 at 2:38 AM syzbot
> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:88b95ef4c780 kmsan: use MSan assembly instrumentation
>> git tree:
>>
> On 7 Nov 2018, at 14:10, Alexander Potapenko wrote:
>
> On Wed, Nov 7, 2018 at 2:38 AM syzbot
> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:88b95ef4c780 kmsan: use MSan assembly instrumentation
>> git tree:
>>
Use the gpiod interface instead of the deprecated old non-descriptor
interface in olpc_dcon_xo_1.c.
Signed-off-by: Nishad Kamdar
---
Changes in v4:
- Move changelog after signed-off line.
Changes in v3:
- Resolve a few compilation errors.
Changes in v2:
- Resolve a few compilation errors.
-
Use the gpiod interface instead of the deprecated old non-descriptor
interface in olpc_dcon_xo_1.c.
Signed-off-by: Nishad Kamdar
---
Changes in v4:
- Move changelog after signed-off line.
Changes in v3:
- Resolve a few compilation errors.
Changes in v2:
- Resolve a few compilation errors.
-
On 07/11/2018 13:10, Alexander Potapenko wrote:
> This appears to be a real bug in KVM.
> Please see a simplified reproducer attached.
Thanks, I agree it's a reael bug. The basic issue is that the
kvm_state->size member is too small (1040) in the KVM_SET_NESTED_STATE
ioctl, aka 0x4080aebf.
One
On 07/11/2018 13:10, Alexander Potapenko wrote:
> This appears to be a real bug in KVM.
> Please see a simplified reproducer attached.
Thanks, I agree it's a reael bug. The basic issue is that the
kvm_state->size member is too small (1040) in the KVM_SET_NESTED_STATE
ioctl, aka 0x4080aebf.
One
On 05/11/2018 17:21, Neil Armstrong wrote:
> The hdmi_5v regulator must be enabled to provide power to the physical HDMI
> PHY and enables the HDMI 5V presence loopback for the monitor.
>
> Fixes: b409f625a6d5 ("ARM64: dts: meson-gx: Add HDMI_5V regulator on selected
> boards")
> Signed-off-by:
On 05/11/2018 17:21, Neil Armstrong wrote:
> The hdmi_5v regulator must be enabled to provide power to the physical HDMI
> PHY and enables the HDMI 5V presence loopback for the monitor.
>
> Fixes: b409f625a6d5 ("ARM64: dts: meson-gx: Add HDMI_5V regulator on selected
> boards")
> Signed-off-by:
On Wed, Nov 07, 2018 at 12:36:52PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 06, 2018 at 01:13:19PM +0530, Nishad Kamdar wrote:
> > Use the gpiod interface instead of the deprecated old non-descriptor
> > interface in olpc_dcon_xo_1.c.
> > ---
> > Changes in v3:
> > - Resolve a few
On Wed, Nov 07, 2018 at 12:36:52PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 06, 2018 at 01:13:19PM +0530, Nishad Kamdar wrote:
> > Use the gpiod interface instead of the deprecated old non-descriptor
> > interface in olpc_dcon_xo_1.c.
> > ---
> > Changes in v3:
> > - Resolve a few
On Tue, Nov 6, 2018 at 10:30 AM, Kirill Tkhai wrote:
> We should sent signal only in case of interrupt is really queued.
> Not a real problem, but this makes the code clearer and intuitive.
>
> Signed-off-by: Kirill Tkhai
> ---
> fs/fuse/dev.c |6 +-
> 1 file changed, 5 insertions(+), 1
On Tue, Nov 6, 2018 at 10:30 AM, Kirill Tkhai wrote:
> We should sent signal only in case of interrupt is really queued.
> Not a real problem, but this makes the code clearer and intuitive.
>
> Signed-off-by: Kirill Tkhai
> ---
> fs/fuse/dev.c |6 +-
> 1 file changed, 5 insertions(+), 1
Hi,
On 07-11-18 13:22, Rafael J. Wysocki wrote:
On Fri, Nov 2, 2018 at 12:07 PM Arnd Bergmann wrote:
We still get a link failure with IOSF_MBI=m when the xpower driver
is built-in:
drivers/acpi/pmic/intel_pmic_xpower.o: In function
`intel_xpower_pmic_update_power':
Hi,
On 07-11-18 13:22, Rafael J. Wysocki wrote:
On Fri, Nov 2, 2018 at 12:07 PM Arnd Bergmann wrote:
We still get a link failure with IOSF_MBI=m when the xpower driver
is built-in:
drivers/acpi/pmic/intel_pmic_xpower.o: In function
`intel_xpower_pmic_update_power':
From: Lucas Stach
This is a new fractional clock type introduced on i.MX8.
The description of this fractional clock can be found here:
https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
Since a lot of clocks on imx8m are formed by a mux, gate, predivider and
divider, the idea here is to combine all of those into one composite clock,
but we need to deal with both predivider and divider at the same time and
therefore we add the imx8m_clk_composite_divider_ops and register
the
From: Lucas Stach
This is a new fractional clock type introduced on i.MX8.
The description of this fractional clock can be found here:
https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
Since a lot of clocks on imx8m are formed by a mux, gate, predivider and
divider, the idea here is to combine all of those into one composite clock,
but we need to deal with both predivider and divider at the same time and
therefore we add the imx8m_clk_composite_divider_ops and register
the
So this is all cleaned up now. The switch from clk to clk_hw registration
is done only for the newly added clock types because changing the older
ones will imply a bigger change. I will spend some time on that, but this
can't be delayed by that since this is needed in order to boot up.
Here is a
From: Lucas Stach
The SCCG is a new PLL type introduced on i.MX8.
The description of this SCCG clock can be found here:
https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
So this is all cleaned up now. The switch from clk to clk_hw registration
is done only for the newly added clock types because changing the older
ones will imply a bigger change. I will spend some time on that, but this
can't be delayed by that since this is needed in order to boot up.
Here is a
From: Lucas Stach
The SCCG is a new PLL type introduced on i.MX8.
The description of this SCCG clock can be found here:
https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
Add driver for the Clock Control Module found on i.MX8MQ.
Signed-off-by: Anson Huang
Signed-off-by: Bai Ping
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
drivers/clk/imx/Makefile | 1 +
drivers/clk/imx/clk-imx8mq.c | 589
Add driver for the Clock Control Module found on i.MX8MQ.
Signed-off-by: Anson Huang
Signed-off-by: Bai Ping
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Sascha Hauer
---
drivers/clk/imx/Makefile | 1 +
drivers/clk/imx/clk-imx8mq.c | 589
From: Lucas Stach
This adds the binding for the i.MX8MQ Clock Controller Module.
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Rob Herring
---
.../devicetree/bindings/clock/imx8mq-clock.txt | 20 ++
include/dt-bindings/clock/imx8mq-clock.h | 395
From: Lucas Stach
This adds the binding for the i.MX8MQ Clock Controller Module.
Signed-off-by: Lucas Stach
Signed-off-by: Abel Vesa
Reviewed-by: Rob Herring
---
.../devicetree/bindings/clock/imx8mq-clock.txt | 20 ++
include/dt-bindings/clock/imx8mq-clock.h | 395
On Tue, Nov 06, 2018 at 12:13:30PM -0600, Rob Herring wrote:
> On Tue, Nov 6, 2018 at 9:53 AM Andy Shevchenko
> wrote:
> >
> > On Tue, Nov 06, 2018 at 05:05:03PM +0200, Heikki Krogerus wrote:
> >
> > > Maybe it would be best to just read the "name" device property in
> > > fwnode_name() and not
On Tue, Nov 06, 2018 at 12:13:30PM -0600, Rob Herring wrote:
> On Tue, Nov 6, 2018 at 9:53 AM Andy Shevchenko
> wrote:
> >
> > On Tue, Nov 06, 2018 at 05:05:03PM +0200, Heikki Krogerus wrote:
> >
> > > Maybe it would be best to just read the "name" device property in
> > > fwnode_name() and not
On Tue, Nov 06, 2018 at 04:46:41PM +0200, Andy Shevchenko wrote:
> On Mon, Nov 05, 2018 at 05:59:28PM +0300, Heikki Krogerus wrote:
> > Replacing struct property_set with the software nodes that
> > were just introduced.
> >
> > The API and functionality for adding properties to devices
> >
On Tue, Nov 06, 2018 at 04:46:41PM +0200, Andy Shevchenko wrote:
> On Mon, Nov 05, 2018 at 05:59:28PM +0300, Heikki Krogerus wrote:
> > Replacing struct property_set with the software nodes that
> > were just introduced.
> >
> > The API and functionality for adding properties to devices
> >
On Wed, Nov 07, 2018 at 07:39:33AM +0300, Dan Carpenter wrote:
> Hi Heikki,
>
> url:
> https://github.com/0day-ci/linux/commits/Heikki-Krogerus/device-property-Introducing-software-nodes/20181106-031310
>
> smatch warnings:
> drivers/base/swnode.c:391 fwnode_create_software_node() error:
On Wed, Nov 07, 2018 at 07:39:33AM +0300, Dan Carpenter wrote:
> Hi Heikki,
>
> url:
> https://github.com/0day-ci/linux/commits/Heikki-Krogerus/device-property-Introducing-software-nodes/20181106-031310
>
> smatch warnings:
> drivers/base/swnode.c:391 fwnode_create_software_node() error:
On Wed, Nov 07, 2018 at 04:31:34AM +0200, Nick Kossifidis wrote:
[...]
>
> Mark and Sudeep thanks a lot for your feedback, I guess you convinced me
> that having a device tree binding for the scheduler is not a correct
> approach.
>
Thanks :)
> It's not a device after all and I agree that the
On Wed, Nov 07, 2018 at 04:31:34AM +0200, Nick Kossifidis wrote:
[...]
>
> Mark and Sudeep thanks a lot for your feedback, I guess you convinced me
> that having a device tree binding for the scheduler is not a correct
> approach.
>
Thanks :)
> It's not a device after all and I agree that the
Hi Christophe,
Boris Brezillon wrote on Wed, 7 Nov 2018
13:23:42 +0100:
> On Wed, 7 Nov 2018 12:08:58 +0100
> Christophe Kerello wrote:
>
> > >> +
> > >> +write_8bit:
> > >> +for (i = 0; i < len; i++)
> > >> +writeb_relaxed(p[i], io_addr_w);
> > >
> > > Is 8bit
On Wed, Oct 17, 2018 at 12:59:44PM -0700, Stephen Boyd wrote:
> Quoting Abel Vesa (2018-09-24 03:39:54)
> > From: Lucas Stach
> >
> > This is a new clock type introduced on i.MX8.
>
> Ok, what's the clock type? Add another sentence please.
>
Added in the next version a link with the pdf
On Wed, Oct 17, 2018 at 12:59:44PM -0700, Stephen Boyd wrote:
> Quoting Abel Vesa (2018-09-24 03:39:54)
> > From: Lucas Stach
> >
> > This is a new clock type introduced on i.MX8.
>
> Ok, what's the clock type? Add another sentence please.
>
Added in the next version a link with the pdf
Hi Christophe,
Boris Brezillon wrote on Wed, 7 Nov 2018
13:23:42 +0100:
> On Wed, 7 Nov 2018 12:08:58 +0100
> Christophe Kerello wrote:
>
> > >> +
> > >> +write_8bit:
> > >> +for (i = 0; i < len; i++)
> > >> +writeb_relaxed(p[i], io_addr_w);
> > >
> > > Is 8bit
On Wed, 7 Nov 2018 12:08:58 +0100
Christophe Kerello wrote:
> >> +
> >> +write_8bit:
> >> + for (i = 0; i < len; i++)
> >> + writeb_relaxed(p[i], io_addr_w);
> >
> > Is 8bit access really enforced by the byte accessor? In this case, how
> > can you be sure 32-bit accesses are doing
I recently had reason to build the Linux kernel (debugging a problem on
OpenSuSE Tumbleweed), and I
got a number of warnings. They are all about 'strncpy' buffers being
possibly 1 byte too short to hold the
trailing NUL in a string. I have sent a log of the warnings attached to
this email;
On Wed, 7 Nov 2018 12:08:58 +0100
Christophe Kerello wrote:
> >> +
> >> +write_8bit:
> >> + for (i = 0; i < len; i++)
> >> + writeb_relaxed(p[i], io_addr_w);
> >
> > Is 8bit access really enforced by the byte accessor? In this case, how
> > can you be sure 32-bit accesses are doing
I recently had reason to build the Linux kernel (debugging a problem on
OpenSuSE Tumbleweed), and I
got a number of warnings. They are all about 'strncpy' buffers being
possibly 1 byte too short to hold the
trailing NUL in a string. I have sent a log of the warnings attached to
this email;
On Fri, Nov 2, 2018 at 12:07 PM Arnd Bergmann wrote:
>
> We still get a link failure with IOSF_MBI=m when the xpower driver
> is built-in:
>
> drivers/acpi/pmic/intel_pmic_xpower.o: In function
> `intel_xpower_pmic_update_power':
> intel_pmic_xpower.c:(.text+0x4f2): undefined reference to
>
On Fri, Nov 2, 2018 at 12:07 PM Arnd Bergmann wrote:
>
> We still get a link failure with IOSF_MBI=m when the xpower driver
> is built-in:
>
> drivers/acpi/pmic/intel_pmic_xpower.o: In function
> `intel_xpower_pmic_update_power':
> intel_pmic_xpower.c:(.text+0x4f2): undefined reference to
>
On Mon, Oct 29, 2018 at 06:32:57PM +, Patrick Bellasi wrote:
> +struct uclamp_se {
> + unsigned int value : SCHED_CAPACITY_SHIFT + 1;
> + unsigned int group_id : order_base_2(UCLAMP_GROUPS);
Are you sure about ob2() ? seems weird we'll end up with 0 for
On Mon, Oct 29, 2018 at 06:32:57PM +, Patrick Bellasi wrote:
> +struct uclamp_se {
> + unsigned int value : SCHED_CAPACITY_SHIFT + 1;
> + unsigned int group_id : order_base_2(UCLAMP_GROUPS);
Are you sure about ob2() ? seems weird we'll end up with 0 for
1101 - 1200 of 1460 matches
Mail list logo
