Hi Laurent,
On 2018-04-25 01:36:42 +0200, Niklas Söderlund wrote:
> Hi Laurent,
>
> Thanks for your patch.
>
> On 2018-04-21 15:44:44 +0300, Laurent Pinchart wrote:
> > The pixel rate, as reported by the V4L2_CID_PIXEL_RATE control, must
> > include both horizontal and vertical blanking. Both
From: Doug Berger
The constants defined in this file are equally useful in assembly and C
source files. The arm64 architecture version of this file allows
inclusion in both assembly and C source files, so this this commit adds
that capability to the arm architecture version so
As we found in sun9i-a80, CPUCFG is a collection of registers that are
mapped to the SoC's signals from each individual processor core and
associated peripherals.
These registers are used for SMP bringup and CPU hotplugging.
Signed-off-by: Mylène Josserand
Move the assembly code for cluster cache enabling and resuming
into an assembly file instead of having it directly in C code.
Remove the CFLAGS because we are using the ARM directive "arch"
instead.
Signed-off-by: Mylène Josserand
Acked-by: Maxime Ripard
Add CCI-400 node and control-port on CPUs needed by SMP bringup.
Signed-off-by: Mylène Josserand
Reviewed-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 41 +++
1 file changed, 41 insertions(+)
diff
The R_CPUCFG is a collection of registers needed for SMP bringup
on clusters and cluster's reset.
For the moment, documentation about this register is found in
Allwinner's code only.
Signed-off-by: Mylène Josserand
Reviewed-by: Chen-Yu Tsai
---
Add the initialization of CNTVOFF for sun8i-a83t.
For boot CPU, create a new machine that handles this
function's call in an "init_early" callback. We need to initialize
CNTVOFF before the arch timer's initialization otherwise, it will
not be taken into account and fails to boot correctly.
The CNTVOFF register from arch timer is uninitialized.
It should be done by the bootloader but it is currently not the case,
even for boot CPU because this SoC is booting in secure mode.
It leads to an random offset value meaning that each CPU will have a
different time, which isn't working very
To prepare the support of sun8i-a83t, add a field in the smp_data
structure to know if we are on sun9i-a80 or sun8i-a83t.
Add also a global variable to retrieve which architecture we are
having.
Signed-off-by: Mylène Josserand
Acked-by: Maxime Ripard
Add the use of enable-method property for SMP support which allows
to handle the SMP support for this specific SoC.
This commit adds enable-method properties to all CPU nodes.
Signed-off-by: Mylène Josserand
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 8
1
To prepare the support for sun8i-a83t, rename the macro that handles
the power-off of clusters because it is different from sun9i-a80 to
sun8i-a83t.
The power off register for clusters are different from a80 and a83t.
Signed-off-by: Mylène Josserand
Acked-by:
Add the support for A83T.
A83T SoC has an additional register than A80 to handle CPU configurations:
R_CPUS_CFG. Information about the register comes from Allwinner's BSP
driver.
An important difference is the Power Off Gating register for clusters
which is BIT(4) in case of SUN9I-A80 and BIT(0)
Now that a common function is available for CNTVOFF's
initialization, let's convert shmobile-apmu code to use
this function.
Signed-off-by: Mylène Josserand
Reviewed-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
Hello everyone,
This is a V9 of my series that adds SMP support for Allwinner sun8i-a83t.
Based on sunxi's tree, sunxi/for-next branch.
Depends on a patch from Doug Berger that allows to include the "cpu-type"
header on assembly files that I included in my series (patch 01).
The difference with
Em Fri, 4 May 2018 16:37:23 +0200
Geert Uytterhoeven escreveu:
> Hi Mauro,
>
> On Fri, May 4, 2018 at 2:13 PM, Mauro Carvalho Chehab
> wrote:
> > With the new vsp1 code changes introduced by changeset
> > f81f9adc4ee1 ("media: v4l: vsp1: Assign
On Tue, May 01, 2018 at 05:27:07PM +0200, Simon Horman wrote:
> On Mon, Apr 30, 2018 at 04:48:13AM +0900, Yoshihiro Kaneko wrote:
> > This series adds SDHI device support for r8a77965.
> >
> > This series is based on the next branch of Ulf Hansson's mmc tree.
> >
> > Masaharu Hayakawa (1):
> >
Hi Mauro,
On Fri, May 4, 2018 at 2:13 PM, Mauro Carvalho Chehab
wrote:
> With the new vsp1 code changes introduced by changeset
> f81f9adc4ee1 ("media: v4l: vsp1: Assign BRU and BRS to pipelines
> dynamically"),
> smatch complains with:
>
Bridge drivers can now (temporarily, in a transition phase) select if
they want to provide a full owner device or keep just providing an
of_node.
By providing a full owner device, the bridge drivers no longer need
to provide an of_node since that node is available via the owner
device.
When all
The .of_node member is going away.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 3d2d3bbd1342..efda02f55c95
It is unused.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_bridge.c | 3 +--
drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 --
include/drm/drm_bridge.h | 4
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git
The .odev owner device will be handy to have around.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_bridge.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index df084db33494..78d186b6831b 100644
---
If the bridge supplier is unbound, this will bring the bridge consumer
down along with the bridge. Thus, there will no longer linger any
dangling pointers from the bridge consumer (the drm_device) to some
non-existent bridge supplier.
Signed-off-by: Peter Rosin
---
Hi!
It was noted by Russel King [1] that bridges (not using components)
might disappear unexpectedly if the owner of the bridge was unbound.
Jyri Sarha had previously noted the same thing with panels [2]. Jyri
came up with using device links to resolve the panel issue, which
was also my
On Fri, May 04, 2018 at 02:22:59PM +0100, Lorenzo Pieralisi wrote:
> On Thu, May 03, 2018 at 10:32:41PM +0300, Sergei Shtylyov wrote:
> > Hello!
> >
> > Here's a set of 5 patches against the 'pci/rcar' branch of Lorenzo
> > Pieralisi's
> > 'pci.git' repo. These are the changes needed for better
On Thu, May 03, 2018 at 02:30:48PM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> The ROHM BD9571MWV PMIC on the Renesas Salvator-X(S) and ULCB
> development boards supports DDR Backup Power, which means that the DDR
> power rails can be kept powered while the main SoC is powered
On Thu, May 03, 2018 at 02:38:27PM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> This patch series fixes a few whitespace issues in DTS files.
Thanks, applied.
On Thu, May 03, 2018 at 10:32:41PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> Here's a set of 5 patches against the 'pci/rcar' branch of Lorenzo Pieralisi's
> 'pci.git' repo. These are the changes needed for better R-Car gen3 support
> (namely for R8A77980 support) plus some PCIe driver
On Thu, May 03, 2018 at 03:02:33PM +0200, Geert Uytterhoeven wrote:
> R8A7796 is R-Car M3-W.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Simon Horman
On Fri, Apr 27, 2018 at 03:34:29PM +0900, Yoshihiro Shimoda wrote:
> This patch set is based on the renesas-devel-20180426-v4.17-rc2 tag
> of renesas.git.
>
> Yoshihiro Shimoda (3):
> arm64: dts: renesas: r8a7795: salvator-xs: enable usb2_phy3 node
> arm64: dts: renesas: r8a7795: salvator-xs:
On Sun, Apr 29, 2018 at 08:26:39PM +0200, Wolfram Sang wrote:
> Add the EEPROM found on Salvator-X and -XS boards for H3, M3-W, and M3-N
> on the IIC_DVFS bus.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Always nice for I2C debugging to have en EEPROM around...
With the new vsp1 code changes introduced by changeset
f81f9adc4ee1 ("media: v4l: vsp1: Assign BRU and BRS to pipelines dynamically"),
smatch complains with:
drivers/media/platform/vsp1/vsp1_drm.c:262 vsp1_du_pipeline_setup_bru()
error: we previously assumed 'pipe->bru' could be null (see
Hi Geert,
Thanks for the feedback.
> Subject: Re: [PATCH v2] pinctrl: sh-pfc: Add r8a77470 PFC support
>
> Hi Biju,
>
> On Tue, Apr 24, 2018 at 1:03 PM, Biju Das wrote:
> > Add PFC support for the R8A77470 SoC including pin groups for some
> > on-chip devices such as
Hi Biju,
On Tue, Apr 24, 2018 at 1:03 PM, Biju Das wrote:
> Add PFC support for the R8A77470 SoC including pin groups for
> some on-chip devices such as SCIF, AVB and MMC.
>
> Signed-off-by: Biju Das
> Reviewed-by: Fabrizio Castro
The renesas-ceu driver intializes the desired mbus_format at 'complete'
time, inspecting the supported subdevice ones, and tuning some
parameters to produce the requested memory format from what the sensor
can produce. Although, the initially selected mbus_format was not
provided to the subdevice
Hi Sergei,
On Sat, Apr 28, 2018 at 8:30 PM, Sergei Shtylyov
wrote:
> On 04/28/2018 08:40 PM, Sergei Shtylyov wrote:
> Subject: Re: [PATCH v2 1/2] pinctrl: sh-pfc: Add r8a77470 PFC support
> On Wed, Apr 4, 2018 at 5:22 PM, Biju Das
Hi Simon-san,
2018-05-02 0:30 GMT+09:00 Simon Horman :
> On Mon, Apr 30, 2018 at 04:48:16AM +0900, Yoshihiro Kaneko wrote:
>> From: Takeshi Kihara
>>
>> Add SDHI nodes to the DT of the r8a77965 SoC.
>>
>> Based on several similar patches of the
Hi Geert-san,
2018-05-04 17:30 GMT+09:00 Geert Uytterhoeven :
> Hi Kaneko-san,
>
> On Fri, May 4, 2018 at 10:28 AM, Yoshihiro Kaneko
> wrote:
>> 2018-05-02 18:16 GMT+09:00 Geert Uytterhoeven :
>>> On Sun, Apr 29, 2018 at 9:48
Hello,
2018-05-02 17:14 GMT+09:00 Wolfram Sang :
>
>> With the current state of the driver this patch should be fine,
>> modulo the changes suggested above. But once HS400 support is merged
>> some logic will be required to disable that feature for the r8a77965
>> until HS400
Hi Kaneko-san,
On Fri, May 4, 2018 at 10:28 AM, Yoshihiro Kaneko wrote:
> 2018-05-02 18:16 GMT+09:00 Geert Uytterhoeven :
>> On Sun, Apr 29, 2018 at 9:48 PM, Yoshihiro Kaneko
>> wrote:
>>> From: Takeshi Kihara
Hi Geert-san,
2018-05-02 18:16 GMT+09:00 Geert Uytterhoeven :
> Hi Kaneko-san,
>
> On Sun, Apr 29, 2018 at 9:48 PM, Yoshihiro Kaneko
> wrote:
>> From: Takeshi Kihara
>>
>> This patch adds SDHI{0,1,2,3} pins, groups and
Hi Sergei,
On Fri, Apr 27, 2018 at 9:12 PM, Sergei Shtylyov
wrote:
> Define the generic R8A77980 part of the CAN-FD device node.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov
On Fri, Apr 27, 2018 at 1:21 PM, Bartlomiej Zolnierkiewicz
wrote:
> Since commit a521422ea4ae ("ARM: shmobile: mackerel: Remove Legacy C
> board code") MERAM functionality is unused. Remove it.
>
> Cc: Simon Horman
> Cc: Laurent Pinchart
On Fri, Apr 27, 2018 at 1:21 PM, Bartlomiej Zolnierkiewicz
wrote:
> Since commit a521422ea4ae ("ARM: shmobile: mackerel: Remove Legacy C
> board code") MERAM functionality is unused. Remove it.
>
> Cc: Simon Horman
> Cc: Laurent Pinchart
Hi Rob,
On Wed, May 2, 2018 at 4:32 AM, Rob Herring wrote:
> On Sun, Apr 15, 2018 at 2:09 PM, Rich Felker wrote:
>> On Sun, Apr 15, 2018 at 08:58:42PM +0200, Geert Uytterhoeven wrote:
>>> On Sun, Apr 15, 2018 at 2:34 AM, Rich Felker
44 matches
Mail list logo