[RFC,4/6] ARM: dts: msm8974: add display support

Submitted by Brian Masney on May 5, 2019, 1:04 p.m.

Details

Message ID 20190505130413.32253-5-masneyb@onstation.org
State New
Headers show
Series "ARM: qcom: initial Nexus 5 display support" ( rev: 1 ) in Freedreno

Not browsing as part of any series.

Commit Message

Brian Masney May 5, 2019, 1:04 p.m.
Add the MDP5, DSI and DSI PHY blocks for the display found on the
msm8974 SoCs. This is based on work from msm8916.dtsi and Jonathan
Marek.

Signed-off-by: Brian Masney <masneyb@onstation.org>
---
 arch/arm/boot/dts/qcom-msm8974.dtsi | 132 ++++++++++++++++++++++++++++
 1 file changed, 132 insertions(+)

Patch hide | download patch | download mbox

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 45b5c8ef0374..3f613c5b95a1 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -3,6 +3,7 @@ 
 
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/qcom,gcc-msm8974.h>
+#include <dt-bindings/clock/qcom,mmcc-msm8974.h>
 #include <dt-bindings/clock/qcom,rpmcc.h>
 #include <dt-bindings/reset/qcom,gcc-msm8974.h>
 #include <dt-bindings/gpio/gpio.h>
@@ -1085,6 +1086,137 @@ 
 				};
 			};
 		};
+
+		mdss: mdss@fd900000 {
+			status = "disabled";
+
+			compatible = "qcom,mdss";
+			reg = <0xfd900000 0x100>,
+			      <0xfd924000 0x1000>;
+			reg-names = "mdss_phys",
+			            "vbif_phys";
+
+			power-domains = <&mmcc MDSS_GDSC>;
+
+			clocks = <&mmcc MDSS_AHB_CLK>,
+			         <&mmcc MDSS_AXI_CLK>,
+			         <&mmcc MDSS_VSYNC_CLK>;
+			clock-names = "iface",
+			              "bus",
+			              "vsync";
+
+			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+
+			interrupt-controller;
+			#interrupt-cells = <1>;
+
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			mdp: mdp@fd900000 {
+				status = "disabled";
+
+				compatible = "qcom,mdp5";
+				reg = <0xfd900100 0x22000>;
+				reg-names = "mdp_phys";
+
+				interrupt-parent = <&mdss>;
+				interrupts = <0 0>;
+
+				clocks = <&mmcc MDSS_AHB_CLK>,
+					 <&mmcc MDSS_AXI_CLK>,
+					 <&mmcc MDSS_MDP_CLK>,
+					 <&mmcc MDSS_VSYNC_CLK>;
+				clock-names = "iface",
+				              "bus",
+				              "core",
+				              "vsync";
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port@0 {
+						reg = <0>;
+						mdp5_intf1_out: endpoint {
+							remote-endpoint = <&dsi0_in>;
+						};
+					};
+				};
+			};
+
+			dsi0: dsi@fd922800 {
+				status = "disabled";
+
+				compatible = "qcom,mdss-dsi-ctrl";
+				reg = <0xfd922800 0x1f8>;
+				reg-names = "dsi_ctrl";
+
+				interrupt-parent = <&mdss>;
+				interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
+
+				assigned-clocks = <&mmcc BYTE0_CLK_SRC>,
+				                  <&mmcc PCLK0_CLK_SRC>;
+				assigned-clock-parents = <&dsi_phy0 0>,
+				                         <&dsi_phy0 1>;
+
+				clocks = <&mmcc MDSS_MDP_CLK>,
+				         <&mmcc MDSS_AHB_CLK>,
+				         <&mmcc MDSS_AXI_CLK>,
+				         <&mmcc MDSS_BYTE0_CLK>,
+				         <&mmcc MDSS_PCLK0_CLK>,
+				         <&mmcc MDSS_ESC0_CLK>,
+				         <&mmcc MMSS_MISC_AHB_CLK>;
+				clock-names = "mdp_core",
+				              "iface",
+				              "bus",
+				              "byte",
+				              "pixel",
+				              "core",
+				              "core_mmss";
+
+				phys = <&dsi_phy0>;
+				phy-names = "dsi-phy";
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port@0 {
+						reg = <0>;
+						dsi0_in: endpoint {
+							remote-endpoint = <&mdp5_intf1_out>;
+						};
+					};
+
+					port@1 {
+						reg = <1>;
+						dsi0_out: endpoint {
+						};
+					};
+				};
+			};
+
+			dsi_phy0: dsi-phy@fd922a00 {
+				status = "disabled";
+
+				compatible = "qcom,dsi-phy-28nm-hpm";
+				reg = <0xfd922a00 0xd4>,
+				      <0xfd922b00 0x280>,
+				      <0xfd922d80 0x30>;
+				reg-names = "dsi_pll",
+				            "dsi_phy",
+				            "dsi_phy_regulator";
+
+				#clock-cells = <1>;
+				#phy-cells = <0>;
+				qcom,dsi-phy-index = <0>;
+
+				clocks = <&mmcc MDSS_AHB_CLK>;
+				clock-names = "iface";
+			};
+		};
 	};
 
 	smd {

Comments

On Sun, May 5, 2019 at 3:04 PM Brian Masney <masneyb@onstation.org> wrote:

> Add the MDP5, DSI and DSI PHY blocks for the display found on the
> msm8974 SoCs. This is based on work from msm8916.dtsi and Jonathan
> Marek.
>
> Signed-off-by: Brian Masney <masneyb@onstation.org>

From my limited understanding it looks good:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
On Sun 05 May 06:04 PDT 2019, Brian Masney wrote:
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
[..]
> +			dsi0: dsi@fd922800 {
> +				status = "disabled";
> +
> +				compatible = "qcom,mdss-dsi-ctrl";
> +				reg = <0xfd922800 0x1f8>;
> +				reg-names = "dsi_ctrl";
> +
> +				interrupt-parent = <&mdss>;
> +				interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
> +
> +				assigned-clocks = <&mmcc BYTE0_CLK_SRC>,
> +				                  <&mmcc PCLK0_CLK_SRC>;
> +				assigned-clock-parents = <&dsi_phy0 0>,
> +				                         <&dsi_phy0 1>;
> +
> +				clocks = <&mmcc MDSS_MDP_CLK>,
> +				         <&mmcc MDSS_AHB_CLK>,
> +				         <&mmcc MDSS_AXI_CLK>,
> +				         <&mmcc MDSS_BYTE0_CLK>,
> +				         <&mmcc MDSS_PCLK0_CLK>,
> +				         <&mmcc MDSS_ESC0_CLK>,
> +				         <&mmcc MMSS_MISC_AHB_CLK>;
> +				clock-names = "mdp_core",
> +				              "iface",
> +				              "bus",
> +				              "byte",
> +				              "pixel",
> +				              "core",
> +				              "core_mmss";

Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some
underrun error from DSI. You don't see anything like this?

(These clocks are controlled by msm_bus downstream and should be driven
by interconnect upstream)


Apart from this, I think this looks nice. Happy to see the progress.

Regards,
Bjorn
On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote:
> On Sun 05 May 06:04 PDT 2019, Brian Masney wrote:
> > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> [..]
> > +				clocks = <&mmcc MDSS_MDP_CLK>,
> > +				         <&mmcc MDSS_AHB_CLK>,
> > +				         <&mmcc MDSS_AXI_CLK>,
> > +				         <&mmcc MDSS_BYTE0_CLK>,
> > +				         <&mmcc MDSS_PCLK0_CLK>,
> > +				         <&mmcc MDSS_ESC0_CLK>,
> > +				         <&mmcc MMSS_MISC_AHB_CLK>;
> > +				clock-names = "mdp_core",
> > +				              "iface",
> > +				              "bus",
> > +				              "byte",
> > +				              "pixel",
> > +				              "core",
> > +				              "core_mmss";
> 
> Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some
> underrun error from DSI. You don't see anything like this?
> 
> (These clocks are controlled by msm_bus downstream and should be driven
> by interconnect upstream)
> 
> 
> Apart from this, I think this looks nice. Happy to see the progress.

No, I'm not seeing an underrun errors from the DSI. I think the clocks
are fine since I'm able to get this working with 4.17 using these same
clocks. I just sent out v2 and the cover letter has some details, along
with the full dmesg.

Brian
On Wed, May 8, 2019 at 7:16 PM Brian Masney <masneyb@onstation.org> wrote:
>
> On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote:
> > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote:
> > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > [..]
> > > +                           clocks = <&mmcc MDSS_MDP_CLK>,
> > > +                                    <&mmcc MDSS_AHB_CLK>,
> > > +                                    <&mmcc MDSS_AXI_CLK>,
> > > +                                    <&mmcc MDSS_BYTE0_CLK>,
> > > +                                    <&mmcc MDSS_PCLK0_CLK>,
> > > +                                    <&mmcc MDSS_ESC0_CLK>,
> > > +                                    <&mmcc MMSS_MISC_AHB_CLK>;
> > > +                           clock-names = "mdp_core",
> > > +                                         "iface",
> > > +                                         "bus",
> > > +                                         "byte",
> > > +                                         "pixel",
> > > +                                         "core",
> > > +                                         "core_mmss";
> >
> > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some
> > underrun error from DSI. You don't see anything like this?
> >
> > (These clocks are controlled by msm_bus downstream and should be driven
> > by interconnect upstream)
> >
> >
> > Apart from this, I think this looks nice. Happy to see the progress.
>
> No, I'm not seeing an underrun errors from the DSI. I think the clocks
> are fine since I'm able to get this working with 4.17 using these same
> clocks. I just sent out v2 and the cover letter has some details, along
> with the full dmesg.

since we don't have interconnect driver for 8974, I guess there is
some chance that things work or not based on how lk leaves things?

BR,
-R
On Wed 08 May 19:25 PDT 2019, Rob Clark wrote:

> On Wed, May 8, 2019 at 7:16 PM Brian Masney <masneyb@onstation.org> wrote:
> >
> > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote:
> > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote:
> > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > [..]
> > > > +                           clocks = <&mmcc MDSS_MDP_CLK>,
> > > > +                                    <&mmcc MDSS_AHB_CLK>,
> > > > +                                    <&mmcc MDSS_AXI_CLK>,
> > > > +                                    <&mmcc MDSS_BYTE0_CLK>,
> > > > +                                    <&mmcc MDSS_PCLK0_CLK>,
> > > > +                                    <&mmcc MDSS_ESC0_CLK>,
> > > > +                                    <&mmcc MMSS_MISC_AHB_CLK>;
> > > > +                           clock-names = "mdp_core",
> > > > +                                         "iface",
> > > > +                                         "bus",
> > > > +                                         "byte",
> > > > +                                         "pixel",
> > > > +                                         "core",
> > > > +                                         "core_mmss";
> > >
> > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some
> > > underrun error from DSI. You don't see anything like this?
> > >
> > > (These clocks are controlled by msm_bus downstream and should be driven
> > > by interconnect upstream)
> > >
> > >
> > > Apart from this, I think this looks nice. Happy to see the progress.
> >
> > No, I'm not seeing an underrun errors from the DSI. I think the clocks
> > are fine since I'm able to get this working with 4.17 using these same
> > clocks. I just sent out v2 and the cover letter has some details, along
> > with the full dmesg.
> 
> since we don't have interconnect driver for 8974, I guess there is
> some chance that things work or not based on how lk leaves things?
> 

Right, I guess the bootloader on my device does not leave the busses
ticking - perhaps there's a boot splash involved on Brian's device?

Regardless, this works on Nexus 5 and allows Brian to make further
progress so I'm all for merging it.

Regards,
Bjorn
On Wed, May 08, 2019 at 08:00:47PM -0700, Bjorn Andersson wrote:
> On Wed 08 May 19:25 PDT 2019, Rob Clark wrote:
> 
> > On Wed, May 8, 2019 at 7:16 PM Brian Masney <masneyb@onstation.org> wrote:
> > >
> > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote:
> > > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote:
> > > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > > [..]
> > > > > +                           clocks = <&mmcc MDSS_MDP_CLK>,
> > > > > +                                    <&mmcc MDSS_AHB_CLK>,
> > > > > +                                    <&mmcc MDSS_AXI_CLK>,
> > > > > +                                    <&mmcc MDSS_BYTE0_CLK>,
> > > > > +                                    <&mmcc MDSS_PCLK0_CLK>,
> > > > > +                                    <&mmcc MDSS_ESC0_CLK>,
> > > > > +                                    <&mmcc MMSS_MISC_AHB_CLK>;
> > > > > +                           clock-names = "mdp_core",
> > > > > +                                         "iface",
> > > > > +                                         "bus",
> > > > > +                                         "byte",
> > > > > +                                         "pixel",
> > > > > +                                         "core",
> > > > > +                                         "core_mmss";
> > > >
> > > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some
> > > > underrun error from DSI. You don't see anything like this?
> > > >
> > > > (These clocks are controlled by msm_bus downstream and should be driven
> > > > by interconnect upstream)
> > > >
> > > >
> > > > Apart from this, I think this looks nice. Happy to see the progress.
> > >
> > > No, I'm not seeing an underrun errors from the DSI. I think the clocks
> > > are fine since I'm able to get this working with 4.17 using these same
> > > clocks. I just sent out v2 and the cover letter has some details, along
> > > with the full dmesg.
> > 
> > since we don't have interconnect driver for 8974, I guess there is
> > some chance that things work or not based on how lk leaves things?
> > 
> 
> Right, I guess the bootloader on my device does not leave the busses
> ticking - perhaps there's a boot splash involved on Brian's device?
> 
> Regardless, this works on Nexus 5 and allows Brian to make further
> progress so I'm all for merging it.

There is a boot splash on the Nexus 5 and that may explain a behavior
that I observed. I attempted to add reset GPIO support to the simple
panel driver and the screen will clear but nothing will come on the
screen after a hard reset, even on 4.17. To be sure, I got the timing
information for how long to leave the GPIO high and low from the
downstream MSM 3.4 sources. That's when I had a script port all of the
~400 panel on commands in the downstream device tree to a new panel
driver.

With the latest kernel kernel having a delay showing the console text,
I observe a brief second where the boot splash is shown along with the
startup text from Linux. A full refresh is performed and the boot
splash goes away. I don't see this with the 4.17 kernel; perhaps maybe
the full refresh occurs quick enough that its not noticeable.

Can you point me to where the interconnect API is in the downstream
MSM 3.4 sources? https://github.com/AICP/kernel_lge_hammerhead
It looks like its in drivers/interconnect/ in the upstream sources.

Brian
On Thu, May 9, 2019 at 12:12 AM Brian Masney <masneyb@onstation.org> wrote:
>
> On Wed, May 08, 2019 at 08:00:47PM -0700, Bjorn Andersson wrote:
> > On Wed 08 May 19:25 PDT 2019, Rob Clark wrote:
> >
> > > On Wed, May 8, 2019 at 7:16 PM Brian Masney <masneyb@onstation.org> wrote:
> > > >
> > > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote:
> > > > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote:
> > > > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > > > [..]
> > > > > > +                           clocks = <&mmcc MDSS_MDP_CLK>,
> > > > > > +                                    <&mmcc MDSS_AHB_CLK>,
> > > > > > +                                    <&mmcc MDSS_AXI_CLK>,
> > > > > > +                                    <&mmcc MDSS_BYTE0_CLK>,
> > > > > > +                                    <&mmcc MDSS_PCLK0_CLK>,
> > > > > > +                                    <&mmcc MDSS_ESC0_CLK>,
> > > > > > +                                    <&mmcc MMSS_MISC_AHB_CLK>;
> > > > > > +                           clock-names = "mdp_core",
> > > > > > +                                         "iface",
> > > > > > +                                         "bus",
> > > > > > +                                         "byte",
> > > > > > +                                         "pixel",
> > > > > > +                                         "core",
> > > > > > +                                         "core_mmss";
> > > > >
> > > > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some
> > > > > underrun error from DSI. You don't see anything like this?
> > > > >
> > > > > (These clocks are controlled by msm_bus downstream and should be driven
> > > > > by interconnect upstream)
> > > > >
> > > > >
> > > > > Apart from this, I think this looks nice. Happy to see the progress.
> > > >
> > > > No, I'm not seeing an underrun errors from the DSI. I think the clocks
> > > > are fine since I'm able to get this working with 4.17 using these same
> > > > clocks. I just sent out v2 and the cover letter has some details, along
> > > > with the full dmesg.
> > >
> > > since we don't have interconnect driver for 8974, I guess there is
> > > some chance that things work or not based on how lk leaves things?
> > >
> >
> > Right, I guess the bootloader on my device does not leave the busses
> > ticking - perhaps there's a boot splash involved on Brian's device?
> >
> > Regardless, this works on Nexus 5 and allows Brian to make further
> > progress so I'm all for merging it.
>
> There is a boot splash on the Nexus 5 and that may explain a behavior
> that I observed. I attempted to add reset GPIO support to the simple
> panel driver and the screen will clear but nothing will come on the
> screen after a hard reset, even on 4.17. To be sure, I got the timing
> information for how long to leave the GPIO high and low from the
> downstream MSM 3.4 sources. That's when I had a script port all of the
> ~400 panel on commands in the downstream device tree to a new panel
> driver.
>
> With the latest kernel kernel having a delay showing the console text,
> I observe a brief second where the boot splash is shown along with the
> startup text from Linux. A full refresh is performed and the boot
> splash goes away. I don't see this with the 4.17 kernel; perhaps maybe
> the full refresh occurs quick enough that its not noticeable.
>
> Can you point me to where the interconnect API is in the downstream
> MSM 3.4 sources? https://github.com/AICP/kernel_lge_hammerhead
> It looks like its in drivers/interconnect/ in the upstream sources.
>

Looks like this is the thing:

https://github.com/AICP/kernel_lge_hammerhead/tree/n7.1/arch/arm/mach-msm/msm_bus

(ahh, mach-msm... blast from the past..)

BR,
-R
On Thu 09 May 00:12 PDT 2019, Brian Masney wrote:

> On Wed, May 08, 2019 at 08:00:47PM -0700, Bjorn Andersson wrote:
> > On Wed 08 May 19:25 PDT 2019, Rob Clark wrote:
> > 
> > > On Wed, May 8, 2019 at 7:16 PM Brian Masney <masneyb@onstation.org> wrote:
> > > >
> > > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote:
> > > > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote:
> > > > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > > > [..]
> > > > > > +                           clocks = <&mmcc MDSS_MDP_CLK>,
> > > > > > +                                    <&mmcc MDSS_AHB_CLK>,
> > > > > > +                                    <&mmcc MDSS_AXI_CLK>,
> > > > > > +                                    <&mmcc MDSS_BYTE0_CLK>,
> > > > > > +                                    <&mmcc MDSS_PCLK0_CLK>,
> > > > > > +                                    <&mmcc MDSS_ESC0_CLK>,
> > > > > > +                                    <&mmcc MMSS_MISC_AHB_CLK>;
> > > > > > +                           clock-names = "mdp_core",
> > > > > > +                                         "iface",
> > > > > > +                                         "bus",
> > > > > > +                                         "byte",
> > > > > > +                                         "pixel",
> > > > > > +                                         "core",
> > > > > > +                                         "core_mmss";
> > > > >
> > > > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some
> > > > > underrun error from DSI. You don't see anything like this?
> > > > >
> > > > > (These clocks are controlled by msm_bus downstream and should be driven
> > > > > by interconnect upstream)
> > > > >
> > > > >
> > > > > Apart from this, I think this looks nice. Happy to see the progress.
> > > >
> > > > No, I'm not seeing an underrun errors from the DSI. I think the clocks
> > > > are fine since I'm able to get this working with 4.17 using these same
> > > > clocks. I just sent out v2 and the cover letter has some details, along
> > > > with the full dmesg.
> > > 
> > > since we don't have interconnect driver for 8974, I guess there is
> > > some chance that things work or not based on how lk leaves things?
> > > 
> > 
> > Right, I guess the bootloader on my device does not leave the busses
> > ticking - perhaps there's a boot splash involved on Brian's device?
> > 
> > Regardless, this works on Nexus 5 and allows Brian to make further
> > progress so I'm all for merging it.
> 
> There is a boot splash on the Nexus 5 and that may explain a behavior
> that I observed. I attempted to add reset GPIO support to the simple
> panel driver and the screen will clear but nothing will come on the
> screen after a hard reset, even on 4.17. To be sure, I got the timing
> information for how long to leave the GPIO high and low from the
> downstream MSM 3.4 sources. That's when I had a script port all of the
> ~400 panel on commands in the downstream device tree to a new panel
> driver.
> 
> With the latest kernel kernel having a delay showing the console text,
> I observe a brief second where the boot splash is shown along with the
> startup text from Linux. A full refresh is performed and the boot
> splash goes away. I don't see this with the 4.17 kernel; perhaps maybe
> the full refresh occurs quick enough that its not noticeable.
> 
> Can you point me to where the interconnect API is in the downstream
> MSM 3.4 sources? https://github.com/AICP/kernel_lge_hammerhead
> It looks like its in drivers/interconnect/ in the upstream sources.
> 

The data will be 8974 specific, but the plumbing should be reusable from
8916 or 404. Hopefully we can get those landed shortly.

You can find the latest incarnation here:
https://lore.kernel.org/lkml/20190415104357.5305-1-georgi.djakov@linaro.org/

Regards,
Bjorn