Re: [PATCH 4/4] vgacon, arch/*: remove unused screen_info definitions
On 7/7/23 04:52, Arnd Bergmann wrote: From: Arnd Bergmann A number of architectures either kept the screen_info definition for historical purposes as it used to be required by the generic VT code, or they copied it from another architecture in order to build the VGA console driver in an allmodconfig build. Now that vgacon no longer builds on these architectures, remove the stale definitions. Signed-off-by: Arnd Bergmann --- arch/csky/kernel/setup.c | 12 arch/hexagon/kernel/Makefile | 2 -- arch/hexagon/kernel/screen_info.c | 3 --- arch/nios2/kernel/setup.c | 5 - Acked-by: Dinh Nguyen
Re: [PATCH v3 29/65] clk: socfpga: gate: Add a determine_rate hook
Hi Maxime,
On 5/4/23 12:04, Maxime Ripard wrote:
Hi Dinh,
On Thu, Apr 27, 2023 at 02:09:48PM -0500, Dinh Nguyen wrote:
Hi Maxime,
On 4/25/23 09:48, Maxime Ripard wrote:
Hi Dinh,
On Mon, Apr 24, 2023 at 01:32:28PM -0500, Dinh Nguyen wrote:
On 4/4/23 05:11, Maxime Ripard wrote:
The SoCFGPA gate clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to clk_set_rate(), with
determine_rate() figuring out which parent is the best suited for a
given rate.
The other trigger would be a call to clk_set_parent(), but it's far less
used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an
oversight. However, it could also be an explicit decision by the
original author to avoid any reparenting but through an explicit call to
clk_set_parent().
The latter case would be equivalent to setting the flag
CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
to __clk_mux_determine_rate(). Indeed, if no determine_rate
implementation is provided, clk_round_rate() (through
clk_core_round_rate_nolock()) will call itself on the parent if
CLK_SET_RATE_PARENT is set, and will not change the clock rate
otherwise. __clk_mux_determine_rate() has the exact same behavior when
CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our
behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard
---
drivers/clk/socfpga/clk-gate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c
index 32ccda960f28..cbba8462a09e 100644
--- a/drivers/clk/socfpga/clk-gate.c
+++ b/drivers/clk/socfpga/clk-gate.c
@@ -110,6 +110,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw
*hwclk,
static struct clk_ops gateclk_ops = {
.recalc_rate = socfpga_clk_recalc_rate,
+ .determine_rate = __clk_mux_determine_rate,
.get_parent = socfpga_clk_get_parent,
.set_parent = socfpga_clk_set_parent,
};
@@ -166,7 +167,7 @@ void __init socfpga_gate_init(struct device_node *node)
init.name = clk_name;
init.ops = ops;
- init.flags = 0;
+ init.flags = CLK_SET_RATE_NO_REPARENT;
init.num_parents = of_clk_parent_fill(node, parent_name,
SOCFPGA_MAX_PARENTS);
if (init.num_parents < 2) {
This patch broke SoCFPGA boot serial port. The characters are mangled.
Do you have any other access to that board? If so, could you dump
clk_summary in debugfs with and without that patch?
That dump from the clk_summary are identical for both cases.
Thanks for testing
I'm a bit confused, there should be no difference in behaviour, and if
there was any difference I would expect the clock tree to be somewhat
different.
Could you still paste the clk_summary (and dmesg) output? Which UART
driver is being used?
Also, is there a way for me to test it somehow?
Apologies, but there is a diff with/without this patch:
With patch:
< l4_sp_clk 330 1
0 0 5 ?
---
Without patch:
> l4_sp_clk 440 1
0 0 5 ?
The enable/prepare count is 4 instead of 3 in the case of a working
UART. The debug uart is using the lp_sp_clk.
The Cyclone5 devkits are pretty cheap if you want to get one.
Here is the full out of clk_summary:
# cat /sys/kernel/debug/clk/clk_summary
enable prepare protect
duty hardware
clock countcountcount rate
accuracy phase cycleenable
---
osc1 550 2500
0 0 5 Y
sdram_pll 000 8
0 0 5 Y
h2f_usr2_clk 000 1
0 0 5 Y
h2f_user2_clk 000 1
0 0 5 ?
ddr_dq_clk 000 4
0 0 5 Y
ddr_dq_clk_gate 000 4
0 0 5 ?
ddr_2x_dqs_clk 000 8
0 0 5 Y
ddr_2x_dqs_clk_gate 000 8
0 0 5 ?
ddr_dqs_clk000 4
0 0 5 Y
ddr_dqs_clk_gate
Re: [PATCH v3 29/65] clk: socfpga: gate: Add a determine_rate hook
Hi Maxime,
On 4/25/23 09:48, Maxime Ripard wrote:
Hi Dinh,
On Mon, Apr 24, 2023 at 01:32:28PM -0500, Dinh Nguyen wrote:
On 4/4/23 05:11, Maxime Ripard wrote:
The SoCFGPA gate clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to clk_set_rate(), with
determine_rate() figuring out which parent is the best suited for a
given rate.
The other trigger would be a call to clk_set_parent(), but it's far less
used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an
oversight. However, it could also be an explicit decision by the
original author to avoid any reparenting but through an explicit call to
clk_set_parent().
The latter case would be equivalent to setting the flag
CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
to __clk_mux_determine_rate(). Indeed, if no determine_rate
implementation is provided, clk_round_rate() (through
clk_core_round_rate_nolock()) will call itself on the parent if
CLK_SET_RATE_PARENT is set, and will not change the clock rate
otherwise. __clk_mux_determine_rate() has the exact same behavior when
CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our
behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard
---
drivers/clk/socfpga/clk-gate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c
index 32ccda960f28..cbba8462a09e 100644
--- a/drivers/clk/socfpga/clk-gate.c
+++ b/drivers/clk/socfpga/clk-gate.c
@@ -110,6 +110,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw
*hwclk,
static struct clk_ops gateclk_ops = {
.recalc_rate = socfpga_clk_recalc_rate,
+ .determine_rate = __clk_mux_determine_rate,
.get_parent = socfpga_clk_get_parent,
.set_parent = socfpga_clk_set_parent,
};
@@ -166,7 +167,7 @@ void __init socfpga_gate_init(struct device_node *node)
init.name = clk_name;
init.ops = ops;
- init.flags = 0;
+ init.flags = CLK_SET_RATE_NO_REPARENT;
init.num_parents = of_clk_parent_fill(node, parent_name,
SOCFPGA_MAX_PARENTS);
if (init.num_parents < 2) {
This patch broke SoCFPGA boot serial port. The characters are mangled.
Do you have any other access to that board? If so, could you dump
clk_summary in debugfs with and without that patch?
That dump from the clk_summary are identical for both cases.
Re: [PATCH v3 29/65] clk: socfpga: gate: Add a determine_rate hook
Hi Maxime,
On 4/4/23 05:11, Maxime Ripard wrote:
The SoCFGPA gate clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to clk_set_rate(), with
determine_rate() figuring out which parent is the best suited for a
given rate.
The other trigger would be a call to clk_set_parent(), but it's far less
used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an
oversight. However, it could also be an explicit decision by the
original author to avoid any reparenting but through an explicit call to
clk_set_parent().
The latter case would be equivalent to setting the flag
CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
to __clk_mux_determine_rate(). Indeed, if no determine_rate
implementation is provided, clk_round_rate() (through
clk_core_round_rate_nolock()) will call itself on the parent if
CLK_SET_RATE_PARENT is set, and will not change the clock rate
otherwise. __clk_mux_determine_rate() has the exact same behavior when
CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our
behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard
---
drivers/clk/socfpga/clk-gate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c
index 32ccda960f28..cbba8462a09e 100644
--- a/drivers/clk/socfpga/clk-gate.c
+++ b/drivers/clk/socfpga/clk-gate.c
@@ -110,6 +110,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw
*hwclk,
static struct clk_ops gateclk_ops = {
.recalc_rate = socfpga_clk_recalc_rate,
+ .determine_rate = __clk_mux_determine_rate,
.get_parent = socfpga_clk_get_parent,
.set_parent = socfpga_clk_set_parent,
};
@@ -166,7 +167,7 @@ void __init socfpga_gate_init(struct device_node *node)
init.name = clk_name;
init.ops = ops;
- init.flags = 0;
+ init.flags = CLK_SET_RATE_NO_REPARENT;
init.num_parents = of_clk_parent_fill(node, parent_name, SOCFPGA_MAX_PARENTS);
if (init.num_parents < 2) {
This patch broke SoCFPGA boot serial port. The characters are mangled.
Dinh
Re: [PATCHv16 1/3] ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite
Hi Hean-Loong:
Please format your commit message like this:
Reviewed-by: Rob Herring
Signed-off-by: Ong, Hean Loong
---
V15:
v14:
The version history needs go after the ---
Dinh
On 6/7/19 9:30 AM, Hean-Loong, Ong wrote:
> From: "Ong, Hean Loong"
>
> Device tree binding for Intel FPGA Video and Image Processing Suite.
> The bindings would set the max width, max height,
> bits per pixel and memory port width.
> The device tree binding only supports the Intel
> Arria10 devkit and its variants. Vendor name retained as altr.
>
> Reviewed-by: Rob Herring
>
> V15:
> Reviewed
>
> V14:
> No Change
>
> V13:
> No change
>
> V12:
> Wrap comments and fix commit message
>
> V11:
> No change
>
> V10:
> No change
>
> V9:
> Remove Display port node
>
> V8:
> *Add port to Display port decoder
>
> V7:
> *Fix OF graph for better description
> *Add description for encoder
>
> V6:
> *Description have not describe DT device in general
>
> V5:
> *remove bindings for bits per symbol as it has only one value which is 8
>
> V4:
> *fix properties that does not describe the values
>
> V3:
> *OF graph not in accordance to graph.txt
>
> V2:
> *Remove Linux driver description
>
> V1:
> *Missing vendor prefix
>
> Signed-off-by: Ong, Hean Loong
> ---
> .../bindings/display/altr,vip-fb2.txt | 63 +++
> 1 file changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
>
> diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> new file mode 100644
> index ..89a3b9e166a8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> @@ -0,0 +1,63 @@
> +Intel Video and Image Processing(VIP) Frame Buffer II bindings
> +
> +Supported hardware: Intel FPGA SoC Arria10 and above with display port IP
> +
> +The Video Frame Buffer II in Video Image Processing (VIP) suite is an IP core
> +that interfaces between system memory and Avalon-ST video ports. The IP core
> +can be configured to support the memory reader (from memory to Avalon-ST)
> +and/or memory writer (from Avalon-ST to memory) interfaces.
> +
> +More information the FPGA video IP component can be acquired from
> +https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\
> +/literature/ug/ug_vip.pdf
> +
> +DT-Bindings:
> +=
> +Required properties:
> +
> +- compatible: "altr,vip-frame-buffer-2.0"
> +- reg: Physical base address and length of the framebuffer controller's
> + registers.
> +- altr,max-width: The maximum width of the framebuffer in pixels.
> +- altr,max-height: The maximum height of the framebuffer in pixels.
> +- altr,mem-port-width = the bus width of the avalon master port
> + on the frame reader
> +
> +Optional sub-nodes:
> +- ports: The connection to the encoder
> +
> +Connections between the Frame Buffer II and other video IP cores in the
> system
> +are modelled using the OF graph DT bindings. The Frame Buffer II node has up
> +to two OF graph ports. When the memory writer interface is enabled, port 0
> +maps to the Avalon-ST Input (din) port. When the memory reader interface is
> +enabled, port 1 maps to the Avalon-ST Output (dout) port.
> +
> +The encoder is built into the FPGA HW design and therefore would not
> +be accessible from the DDR.
> +
> + Port 0 Port1
> +-
> +ARRIA10 AVALON_ST (DIN) AVALON_ST (DOUT)
> +
> +Required Properties Example:
> +
> +
> +framebuffer@10280 {
> + compatible = "altr,vip-frame-buffer-2.0";
> + reg = <0x0001 0x0280 0x0040>;
> + altr,max-width = <1280>;
> + altr,max-height = <720>;
> + altr,mem-port-width = <128>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> + fb_output: endpoint {
> + remote-endpoint =
> <_encoder_input>;
> + };
> + };
> + };
> +};
>
Re: [PATCH10 0/3] Intel FPGA Video and Image Processing Suite
On 08/14/2018 03:57 AM, Hean-Loong, Ong wrote: > From: Ong, Hean Loong > > The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver > patch > here is allocating memory for information to be streamed from the ARM/Linux > to the display port. Basically the driver just wraps the information such as > the pixels to be drawn by the FPGA FrameBuffer 2. > > The piece of hardware in discussion is the SoC FPGA where Linux runs on the > ARM chip and the FGPA is driven by its NIOS soft core with its own > proprietary firmware. This driver doesn't have to ARM specific does it? > > For example the application from the ARM Linux would have to write > information > on the /dev/fb0 with the information stored in the SDRAM to be fetched by the > FPGA framebuffer IP and displayed on the Display Port Monitor. > > > Ong Hean Loong (2): > ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite > ARM:drm ivip Intel FPGA Video and Image Processing Suite > > Ong, Hean Loong (1): > ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite > > .../devicetree/bindings/display/altr,vip-fb2.txt | 63 +++ > arch/arm/configs/socfpga_defconfig |5 + > drivers/gpu/drm/Kconfig|2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/ivip/Kconfig | 14 ++ > drivers/gpu/drm/ivip/Makefile |9 + > drivers/gpu/drm/ivip/intel_vip_conn.c | 95 ++ > drivers/gpu/drm/ivip/intel_vip_core.c | 161 > drivers/gpu/drm/ivip/intel_vip_drv.h | 52 ++ > drivers/gpu/drm/ivip/intel_vip_of.c| 193 > > 10 files changed, 595 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt > create mode 100644 drivers/gpu/drm/ivip/Kconfig > create mode 100644 drivers/gpu/drm/ivip/Makefile > create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c > create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c > create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h > create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c > Can you clarify your commit header? What is "PATCH10", is it version 10? If so, it should be "PATCHv10". You're also missing a few other maintainers in your CC list, the "DRM DRIVERS AND MISC GPU PATCHES" people. Dinh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH10 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
On 08/14/2018 03:57 AM, Hean-Loong, Ong wrote: > From: Ong Hean Loong > > Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II. > The driver only supports the Intel Arria10 devkit and its variants. Why only Arria10? That's not true is it? I remember running a version of this on the Cyclone5 SoCKit. Dinh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
