The UDC clock of the JZ4740 SoC can be gated, but the data structure
representing it was missing the CGU_CLK_GATE flag to make it work.
Signed-off-by: Paul Cercueil
---
drivers/clk/ingenic/jz4740-cgu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The UDC clock of the JZ4740 SoC can be gated, but the data structure
representing it was missing the CGU_CLK_GATE flag to make it work.
Signed-off-by: Paul Cercueil
---
drivers/clk/ingenic/jz4740-cgu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The register field for configuring the divider for the i2s clock
occupies the bits [8-0], which means 9 bits and not 8.
Signed-off-by: Paul Cercueil
---
drivers/clk/ingenic/jz4740-cgu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ingenic/jz4740-cgu.c
The register field for configuring the divider for the i2s clock
occupies the bits [8-0], which means 9 bits and not 8.
Signed-off-by: Paul Cercueil
---
drivers/clk/ingenic/jz4740-cgu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ingenic/jz4740-cgu.c
On Tuesday 05 June 2018 03:37 PM, Keerthy wrote:
> The intc #interrupt-cells is equal to 1. Currently gpio
> node has 2 cells per IRQ which is wrong. Remove the additional
> cell for each of the interrupts.
>
> Signed-off-by: Keerthy
> Fixes: 2e38b946dc54 ("ARM: davinci: da850: add GPIO DT
On Tuesday 05 June 2018 03:37 PM, Keerthy wrote:
> The intc #interrupt-cells is equal to 1. Currently gpio
> node has 2 cells per IRQ which is wrong. Remove the additional
> cell for each of the interrupts.
>
> Signed-off-by: Keerthy
> Fixes: 2e38b946dc54 ("ARM: davinci: da850: add GPIO DT
The c6x is already using memblock and does most of early memory
reservations with it, so it was only a matter of removing the bootmem
initialization and handover of the memory from memblock to bootmem.
Signed-off-by: Mike Rapoport
---
arch/c6x/Kconfig| 1 +
arch/c6x/kernel/setup.c | 26
The c6x is already using memblock and does most of early memory
reservations with it, so it was only a matter of removing the bootmem
initialization and handover of the memory from memblock to bootmem.
Signed-off-by: Mike Rapoport
---
arch/c6x/Kconfig| 1 +
arch/c6x/kernel/setup.c | 26
Enabling HARDENED_USER_COPY causes measurable regressions in
networking performance, up to 8% under UDP flood.
I'm running an a small packet UDP flood using pktgen vs. a host b2b
connected. On the receiver side the UDP packets are processed by a
simple user space process that just reads and
Enabling HARDENED_USER_COPY causes measurable regressions in
networking performance, up to 8% under UDP flood.
I'm running an a small packet UDP flood using pktgen vs. a host b2b
connected. On the receiver side the UDP packets are processed by a
simple user space process that just reads and
On Tue, Jun 19, 2018 at 10:09:05AM +0200, Michal Simek wrote:
> On 6.6.2018 14:41, Michal Simek wrote:
> > Writing zero and NULLs to already initialized fields is not needed.
> > Remove this additional writes.
> >
> > Signed-off-by: Michal Simek
> > ---
> >
> > Changes in v2:
> > - new patch -
On Tue, Jun 19, 2018 at 10:09:05AM +0200, Michal Simek wrote:
> On 6.6.2018 14:41, Michal Simek wrote:
> > Writing zero and NULLs to already initialized fields is not needed.
> > Remove this additional writes.
> >
> > Signed-off-by: Michal Simek
> > ---
> >
> > Changes in v2:
> > - new patch -
On Wed 27-06-18 13:53:49, Jan Kara wrote:
> On Wed 27-06-18 13:32:21, Michal Hocko wrote:
[...]
> > Appart from that, do we really care about 32b here? Big DIO, IB users
> > seem to be 64b only AFAIU.
>
> IMO it is a bad habit to leave unpriviledged-user-triggerable oops in the
> kernel even for
On Wed 27-06-18 13:53:49, Jan Kara wrote:
> On Wed 27-06-18 13:32:21, Michal Hocko wrote:
[...]
> > Appart from that, do we really care about 32b here? Big DIO, IB users
> > seem to be 64b only AFAIU.
>
> IMO it is a bad habit to leave unpriviledged-user-triggerable oops in the
> kernel even for
Use the newly introduced pinctrl_gpio_get_direction to implement the
.get_direction callback.
Signed-off-by: Paul Cercueil
---
drivers/gpio/gpio-ingenic.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpio/gpio-ingenic.c b/drivers/gpio/gpio-ingenic.c
index
Use the newly introduced pinctrl_gpio_get_direction to implement the
.get_direction callback.
Signed-off-by: Paul Cercueil
---
drivers/gpio/gpio-ingenic.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpio/gpio-ingenic.c b/drivers/gpio/gpio-ingenic.c
index
Right now there is a core function to set the direction (input or output)
of a GPIO, pinmux_gpio_set_direction(). This function is provided to the
consumers with two wrappers, pinctrl_gpio_direction_input() /
pinctrl_gpio_direction_output(). Typically, these functions are used
within GPIO drivers,
This function can be used to retrieve the direction (input/output) of a
given GPIO.
It should *ONLY* be used from gpiolib-based GPIO drivers, as part of their
gpio_get_direction() semantics, platforms and individual drivers shall
*NOT* touch pin control GPIO calls.
Signed-off-by: Paul Cercueil
This will allow the GPIO driver to use the previously introduced
pinctrl_gpio_get_direction function to implement its .get_direction
callback.
Signed-off-by: Paul Cercueil
---
drivers/pinctrl/pinctrl-ingenic.c | 13 +
1 file changed, 13 insertions(+)
diff --git
Right now there is a core function to set the direction (input or output)
of a GPIO, pinmux_gpio_set_direction(). This function is provided to the
consumers with two wrappers, pinctrl_gpio_direction_input() /
pinctrl_gpio_direction_output(). Typically, these functions are used
within GPIO drivers,
This function can be used to retrieve the direction (input/output) of a
given GPIO.
It should *ONLY* be used from gpiolib-based GPIO drivers, as part of their
gpio_get_direction() semantics, platforms and individual drivers shall
*NOT* touch pin control GPIO calls.
Signed-off-by: Paul Cercueil
This will allow the GPIO driver to use the previously introduced
pinctrl_gpio_get_direction function to implement its .get_direction
callback.
Signed-off-by: Paul Cercueil
---
drivers/pinctrl/pinctrl-ingenic.c | 13 +
1 file changed, 13 insertions(+)
diff --git
Hi Linus,
Here's a set of (rather RFC) patches, to implement
pinctrl_gpio_get_direction(). I did that, because my gpio-ingenic driver
calls pinctrl_gpio_set_direction() within its gpio_chip's .set_direction
callback, but there was no corresponding function to implement the
.get_direction
Hi Linus,
Here's a set of (rather RFC) patches, to implement
pinctrl_gpio_get_direction(). I did that, because my gpio-ingenic driver
calls pinctrl_gpio_set_direction() within its gpio_chip's .set_direction
callback, but there was no corresponding function to implement the
.get_direction
The .gpio_set_direction() callback was setting inverted direction
for SoCs older than the JZ4770, this restores the correct behaviour.
Signed-off-by: Paul Cercueil
---
drivers/pinctrl/pinctrl-ingenic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The .gpio_set_direction() callback was setting inverted direction
for SoCs older than the JZ4770, this restores the correct behaviour.
Signed-off-by: Paul Cercueil
---
drivers/pinctrl/pinctrl-ingenic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Wed 27-06-18 13:32:21, Michal Hocko wrote:
> On Tue 26-06-18 18:48:25, Jan Kara wrote:
> > On Tue 26-06-18 15:47:57, Michal Hocko wrote:
> > > On Mon 18-06-18 12:21:46, Dan Williams wrote:
> > > [...]
> > > > I do think we should explore a page flag for pages that are "long
> > > > term"
On Wed 27-06-18 13:32:21, Michal Hocko wrote:
> On Tue 26-06-18 18:48:25, Jan Kara wrote:
> > On Tue 26-06-18 15:47:57, Michal Hocko wrote:
> > > On Mon 18-06-18 12:21:46, Dan Williams wrote:
> > > [...]
> > > > I do think we should explore a page flag for pages that are "long
> > > > term"
On Wed, 2018-02-21 at 11:53 +0800, CK Hu wrote:
> Hi, Houlong:
>
> I've one inline comment.
>
> On Wed, 2018-01-31 at 15:28 +0800, houlong@mediatek.com wrote:
> > From: "hs.l...@mediatek.com"
> >
> > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > CMDQ is used
On Wed, 2018-02-21 at 11:53 +0800, CK Hu wrote:
> Hi, Houlong:
>
> I've one inline comment.
>
> On Wed, 2018-01-31 at 15:28 +0800, houlong@mediatek.com wrote:
> > From: "hs.l...@mediatek.com"
> >
> > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > CMDQ is used
On Wed, 27 Jun 2018 13:33:20 +0200
Quentin Schulz wrote:
> Now that we have the logic for skipping CRC check for static UBI volumes
> in the core, let's expose it to users.
>
> This makes use of a padding byte in the volume description data
> structure as a flag. This flag only tell for now
On Wed, 27 Jun 2018 13:33:20 +0200
Quentin Schulz wrote:
> Now that we have the logic for skipping CRC check for static UBI volumes
> in the core, let's expose it to users.
>
> This makes use of a padding byte in the volume description data
> structure as a flag. This flag only tell for now
On Wed, 27 Jun 2018 13:33:19 +0200
Quentin Schulz wrote:
> Some users of static UBI volumes implement their own integrity check,
> thus making the volume CRC check done at open time useless. For
> instance, this is the case when one use the ubiblock + dm-verity +
> squashfs combination, where
On Wed, 27 Jun 2018 13:33:19 +0200
Quentin Schulz wrote:
> Some users of static UBI volumes implement their own integrity check,
> thus making the volume CRC check done at open time useless. For
> instance, this is the case when one use the ubiblock + dm-verity +
> squashfs combination, where
On Wed, 2018-02-21 at 16:05 +0800, CK Hu wrote:
> Hi, Houlong:
>
> I've one more inline comment.
>
> On Wed, 2018-01-31 at 15:28 +0800, houlong@mediatek.com wrote:
> > From: "hs.l...@mediatek.com"
> >
> > Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.
> >
> >
On Wed, 2018-02-21 at 16:05 +0800, CK Hu wrote:
> Hi, Houlong:
>
> I've one more inline comment.
>
> On Wed, 2018-01-31 at 15:28 +0800, houlong@mediatek.com wrote:
> > From: "hs.l...@mediatek.com"
> >
> > Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.
> >
> >
On Wed, 2018-06-27 at 12:40 +0300, Sakari Ailus wrote:
> On Wed, Jun 27, 2018 at 10:19:38AM +0200, Bartosz Golaszewski wrote:
> > 2018-06-27 7:46 GMT+02:00 :
> > > From: Alan Chiang
> > >
> > > The AT24 series chips use 8-bit address by default. If some
> > > chips would like to support more
On Wed, 2018-06-27 at 12:40 +0300, Sakari Ailus wrote:
> On Wed, Jun 27, 2018 at 10:19:38AM +0200, Bartosz Golaszewski wrote:
> > 2018-06-27 7:46 GMT+02:00 :
> > > From: Alan Chiang
> > >
> > > The AT24 series chips use 8-bit address by default. If some
> > > chips would like to support more
Now that we have the logic for skipping CRC check for static UBI volumes
in the core, let's expose it to users.
This makes use of a padding byte in the volume description data
structure as a flag. This flag only tell for now whether we should skip
the CRC check of a volume.
This checks the UBI
Now that we have the logic for skipping CRC check for static UBI volumes
in the core, let's expose it to users.
This makes use of a padding byte in the volume description data
structure as a flag. This flag only tell for now whether we should skip
the CRC check of a volume.
This checks the UBI
Some users of static UBI volumes implement their own integrity check, thus
making the volume CRC check done at open time useless. For instance, this
is the case when one use the ubiblock + dm-verity + squashfs combination,
where dm-verity already checks integrity of the block device but this time
Some users of static UBI volumes implement their own integrity check,
thus making the volume CRC check done at open time useless. For
instance, this is the case when one use the ubiblock + dm-verity +
squashfs combination, where dm-verity already checks integrity of the
block device but this time
Some users of static UBI volumes implement their own integrity check, thus
making the volume CRC check done at open time useless. For instance, this
is the case when one use the ubiblock + dm-verity + squashfs combination,
where dm-verity already checks integrity of the block device but this time
Some users of static UBI volumes implement their own integrity check,
thus making the volume CRC check done at open time useless. For
instance, this is the case when one use the ubiblock + dm-verity +
squashfs combination, where dm-verity already checks integrity of the
block device but this time
On Tue, 2018-02-06 at 10:52 +0800, CK Hu wrote:
> Hi, Houlong:
>
> I've some inline comment.
>
> On Wed, 2018-01-31 at 15:28 +0800, houlong@mediatek.com wrote:
> > From: "hs.l...@mediatek.com"
> >
> > Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.
> >
> >
On Tue, 2018-02-06 at 10:52 +0800, CK Hu wrote:
> Hi, Houlong:
>
> I've some inline comment.
>
> On Wed, 2018-01-31 at 15:28 +0800, houlong@mediatek.com wrote:
> > From: "hs.l...@mediatek.com"
> >
> > Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.
> >
> >
On Tue 26-06-18 18:48:25, Jan Kara wrote:
> On Tue 26-06-18 15:47:57, Michal Hocko wrote:
> > On Mon 18-06-18 12:21:46, Dan Williams wrote:
> > [...]
> > > I do think we should explore a page flag for pages that are "long
> > > term" pinned. Michal asked for something along these lines at LSF / MM
On Tue 26-06-18 18:48:25, Jan Kara wrote:
> On Tue 26-06-18 15:47:57, Michal Hocko wrote:
> > On Mon 18-06-18 12:21:46, Dan Williams wrote:
> > [...]
> > > I do think we should explore a page flag for pages that are "long
> > > term" pinned. Michal asked for something along these lines at LSF / MM
The patch
ASoC: tas517x: add tas5707 support
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
ASoC: tas517x: add tas5707 support
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
ASoC: simple-amplifer: add simple-amplifier compatible
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
ASoC: simple-amplifier: remame dio2125 documentation
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
ASoC: simple-amplifer: add simple-amplifier compatible
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
ASoC: simple-amplifier: remame dio2125 documentation
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
ASoC: tas571x: add tas5707 compatible
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
ASoC: tas571x: add tas5707 compatible
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
On Tue, Jun 26, 2018 at 06:16:04PM +0200, Anna-Maria Gleixner wrote:
> Hi,
>
> during rcu torture tests (TREE04 and TREE07) I noticed, that a
> WARN_ON_ONCE() in sched core triggers on a recent 4.18-rc2 based
> kernel (6f0d349d922b ("Merge
>
On Tue, Jun 26, 2018 at 06:16:04PM +0200, Anna-Maria Gleixner wrote:
> Hi,
>
> during rcu torture tests (TREE04 and TREE07) I noticed, that a
> WARN_ON_ONCE() in sched core triggers on a recent 4.18-rc2 based
> kernel (6f0d349d922b ("Merge
>
On Wed, Jun 27, 2018 at 11:34 AM, Jefferson Carpenter
wrote:
> Is there a way for a user process to mark memory as 'sensitive' or
> 'non-sensitive' when it is allocated? That could allow it not to have to be
> zeroed before being allocated to another process.
Isn't this what we have Meltdown
On Wed, Jun 27, 2018 at 11:34 AM, Jefferson Carpenter
wrote:
> Is there a way for a user process to mark memory as 'sensitive' or
> 'non-sensitive' when it is allocated? That could allow it not to have to be
> zeroed before being allocated to another process.
Isn't this what we have Meltdown
Hi,
On Mon, Jun 25, 2018 at 10:09:41AM -0600, Rob Herring wrote:
> On Mon, Jun 25, 2018 at 8:08 AM Michal Hocko wrote:
> >
> > Hi,
> > I am wondering why do we still keep mm/bootmem.c when most architectures
> > already moved to nobootmem. Is there any fundamental reason why others
> > cannot or
Hi,
On Mon, Jun 25, 2018 at 10:09:41AM -0600, Rob Herring wrote:
> On Mon, Jun 25, 2018 at 8:08 AM Michal Hocko wrote:
> >
> > Hi,
> > I am wondering why do we still keep mm/bootmem.c when most architectures
> > already moved to nobootmem. Is there any fundamental reason why others
> > cannot or
On Tuesday 26 June 2018 04:32 AM, David Lechner wrote:
> On 06/25/2018 11:04 AM, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski
>>
>> The way this function is implemented caused some confusion when
>> converting the TI DaVinci platform to using the common clock framework.
>>
>> Current
On Tuesday 26 June 2018 04:32 AM, David Lechner wrote:
> On 06/25/2018 11:04 AM, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski
>>
>> The way this function is implemented caused some confusion when
>> converting the TI DaVinci platform to using the common clock framework.
>>
>> Current
Hi Suzuki, Jun,
On 27/06/18 12:07, Suzuki K Poulose wrote:
> On 25/06/18 12:39, Jun Yao wrote:
>> When CONFIG_ARM64_VA_BITS_36/CONFIG_ARM64_VA_BITS_39/
>> CONFIG_ARM64_VA_BITS_42 are selected, a block-mapping can be
>> written to swapper_pg_dir. To defend 'KSMA', we move swapper_pg_dir
>> to
Hi Suzuki, Jun,
On 27/06/18 12:07, Suzuki K Poulose wrote:
> On 25/06/18 12:39, Jun Yao wrote:
>> When CONFIG_ARM64_VA_BITS_36/CONFIG_ARM64_VA_BITS_39/
>> CONFIG_ARM64_VA_BITS_42 are selected, a block-mapping can be
>> written to swapper_pg_dir. To defend 'KSMA', we move swapper_pg_dir
>> to
Mein Liebster
Wie geht es Ihnen heute? Ich hoffe, dass es dir und deiner Familie gut
geht zum Ruhm des allmächtigen Gottes. Mein Name ist Beatrice Morgan
Ich bin 52 Jahre alt. Ich war mit dem verstorbenen Mr. James Morgan
verheiratet, der 11 Jahre lang in der Botschaft der Vereinigten
Staaten in
Mein Liebster
Wie geht es Ihnen heute? Ich hoffe, dass es dir und deiner Familie gut
geht zum Ruhm des allmächtigen Gottes. Mein Name ist Beatrice Morgan
Ich bin 52 Jahre alt. Ich war mit dem verstorbenen Mr. James Morgan
verheiratet, der 11 Jahre lang in der Botschaft der Vereinigten
Staaten in
On Friday 01 June 2018 01:55 AM, David Lechner wrote:
> This enables Bluetooth modules in davinic_all_defconfig needed for LEGO
davinci_all_defconfig
> MINDSTORMS EV3.
>
> Signed-off-by: David Lechner
> ---
> arch/arm/configs/davinci_all_defconfig | 9 +
> 1 file changed, 9
On Friday 01 June 2018 01:55 AM, David Lechner wrote:
> This enables Bluetooth modules in davinic_all_defconfig needed for LEGO
davinci_all_defconfig
> MINDSTORMS EV3.
>
> Signed-off-by: David Lechner
> ---
> arch/arm/configs/davinci_all_defconfig | 9 +
> 1 file changed, 9
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
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 | 258
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 | 11 +++
1 file changed, 11 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
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 | 258
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 | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
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
---
Hi Rob,
I don't add your ACK in this version since the dt-binding description
has been changed. Thanks.
---
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
---
Hi Rob,
I don't add your ACK in this version since the dt-binding description
has been changed. Thanks.
---
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 v21:
-rebase on
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 v21:
-rebase on
Hi Boris,
> -Original Message-
> From: Naga Sureshkumar Relli [mailto:nagas...@xilinx.com]
> Sent: Monday, June 25, 2018 2:30 PM
> To: Boris Brezillon
> Cc: rich...@nod.at; dw...@infradead.org; computersforpe...@gmail.com;
> marek.va...@gmail.com; f.faine...@gmail.com;
Hi Boris,
> -Original Message-
> From: Naga Sureshkumar Relli [mailto:nagas...@xilinx.com]
> Sent: Monday, June 25, 2018 2:30 PM
> To: Boris Brezillon
> Cc: rich...@nod.at; dw...@infradead.org; computersforpe...@gmail.com;
> marek.va...@gmail.com; f.faine...@gmail.com;
Hi Jun
On 25/06/18 12:39, Jun Yao wrote:
When CONFIG_ARM64_VA_BITS_36/CONFIG_ARM64_VA_BITS_39/
CONFIG_ARM64_VA_BITS_42 are selected, a block-mapping can be
written to swapper_pg_dir. To defend 'KSMA', we move swapper_pg_dir
to .rodata section when these configurations are selected. At the
same
Hi Jun
On 25/06/18 12:39, Jun Yao wrote:
When CONFIG_ARM64_VA_BITS_36/CONFIG_ARM64_VA_BITS_39/
CONFIG_ARM64_VA_BITS_42 are selected, a block-mapping can be
written to swapper_pg_dir. To defend 'KSMA', we move swapper_pg_dir
to .rodata section when these configurations are selected. At the
same
On Wed 27-06-18 12:47:39, Vlastimil Babka wrote:
> On 06/27/2018 09:54 AM, Michal Hocko wrote:
> > On Wed 27-06-18 09:50:01, Vlastimil Babka wrote:
> >> On 06/27/2018 09:34 AM, Michal Hocko wrote:
> >>> On Tue 26-06-18 10:04:16, Andrew Morton wrote:
> >>>
> >>> And as I've argued before the code
On Wed 27-06-18 12:47:39, Vlastimil Babka wrote:
> On 06/27/2018 09:54 AM, Michal Hocko wrote:
> > On Wed 27-06-18 09:50:01, Vlastimil Babka wrote:
> >> On 06/27/2018 09:34 AM, Michal Hocko wrote:
> >>> On Tue 26-06-18 10:04:16, Andrew Morton wrote:
> >>>
> >>> And as I've argued before the code
On Tuesday 26 June 2018 08:58 PM, David Lechner wrote:
> This adds the power-domains property to both the ECAP and EHRPWM PWM
> nodes. Both have drivers that use pm_runtime to enable the clocks, so
> they need this property in order to find and enable the clock properly.
>
> Signed-off-by: David
On Tuesday 26 June 2018 08:58 PM, David Lechner wrote:
> This adds the power-domains property to both the ECAP and EHRPWM PWM
> nodes. Both have drivers that use pm_runtime to enable the clocks, so
> they need this property in order to find and enable the clock properly.
>
> Signed-off-by: David
On 2018/06/27 8:50, Paul E. McKenney wrote:
> On Wed, Jun 27, 2018 at 05:10:48AM +0900, Tetsuo Handa wrote:
>> As far as I can see,
>>
>> -atomic_set(_callback_count, 1);
>> +atomic_inc(_callback_count);
>>
>> should be sufficient.
>
> I don't see how that helps. For example, suppose
On 2018/06/27 8:50, Paul E. McKenney wrote:
> On Wed, Jun 27, 2018 at 05:10:48AM +0900, Tetsuo Handa wrote:
>> As far as I can see,
>>
>> -atomic_set(_callback_count, 1);
>> +atomic_inc(_callback_count);
>>
>> should be sufficient.
>
> I don't see how that helps. For example, suppose
On 06/27/2018 09:54 AM, Michal Hocko wrote:
> On Wed 27-06-18 09:50:01, Vlastimil Babka wrote:
>> On 06/27/2018 09:34 AM, Michal Hocko wrote:
>>> On Tue 26-06-18 10:04:16, Andrew Morton wrote:
>>>
>>> And as I've argued before the code would be wrong regardless. We would
>>> leak the memory or
On 06/27/2018 09:54 AM, Michal Hocko wrote:
> On Wed 27-06-18 09:50:01, Vlastimil Babka wrote:
>> On 06/27/2018 09:34 AM, Michal Hocko wrote:
>>> On Tue 26-06-18 10:04:16, Andrew Morton wrote:
>>>
>>> And as I've argued before the code would be wrong regardless. We would
>>> leak the memory or
On Tue, Jun 26, 2018 at 10:48:26AM -0700, Paul E. McKenney wrote:
> On Tue, Jun 26, 2018 at 06:32:55PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 26, 2018 at 06:16:04PM +0200, Anna-Maria Gleixner wrote:
> > > Hi,
> > >
> > > during rcu torture tests (TREE04 and TREE07) I noticed, that a
> > >
On Tue, Jun 26, 2018 at 10:48:26AM -0700, Paul E. McKenney wrote:
> On Tue, Jun 26, 2018 at 06:32:55PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 26, 2018 at 06:16:04PM +0200, Anna-Maria Gleixner wrote:
> > > Hi,
> > >
> > > during rcu torture tests (TREE04 and TREE07) I noticed, that a
> > >
On Wed 27-06-18 13:11:44, Mike Rapoport wrote:
> On Mon, Jun 25, 2018 at 10:09:41AM -0600, Rob Herring wrote:
> > On Mon, Jun 25, 2018 at 8:08 AM Michal Hocko wrote:
> > >
> > > Hi,
> > > I am wondering why do we still keep mm/bootmem.c when most architectures
> > > already moved to nobootmem. Is
On Wed 27-06-18 13:11:44, Mike Rapoport wrote:
> On Mon, Jun 25, 2018 at 10:09:41AM -0600, Rob Herring wrote:
> > On Mon, Jun 25, 2018 at 8:08 AM Michal Hocko wrote:
> > >
> > > Hi,
> > > I am wondering why do we still keep mm/bootmem.c when most architectures
> > > already moved to nobootmem. Is
On 2018/06/25 18:36, Dmitry Vyukov wrote:
> On Mon, Jun 25, 2018 at 3:41 AM, Sergey Senozhatsky
> wrote:
>> On (06/22/18 22:06), Tetsuo Handa wrote:
Awesome. If you and Fengguang can combine forces and lead the
whole thing towards "we couldn't care of pr_cont() less", it
would
On 2018/06/25 18:36, Dmitry Vyukov wrote:
> On Mon, Jun 25, 2018 at 3:41 AM, Sergey Senozhatsky
> wrote:
>> On (06/22/18 22:06), Tetsuo Handa wrote:
Awesome. If you and Fengguang can combine forces and lead the
whole thing towards "we couldn't care of pr_cont() less", it
would
On Wed, Jun 20, 2018 at 10:46 PM, Chris Chiu wrote:
> Make asus-wmi notify on hotkey kbd brightness changes, listen for
> brightness events and update the brightness directly in the driver.
> Create new do_kbd_led_set function for in-driver update, and leave
> kbd_led_set for original
On Wed, Jun 20, 2018 at 10:46 PM, Chris Chiu wrote:
> Make asus-wmi notify on hotkey kbd brightness changes, listen for
> brightness events and update the brightness directly in the driver.
> Create new do_kbd_led_set function for in-driver update, and leave
> kbd_led_set for original
701 - 800 of 1028 matches
Mail list logo
