On Fri, 13 May 2016, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> DRM_DEBUG_ATOMIC generates a lot of noise that no one normally cares
> about. However error paths everyone cares about, so hiding thea error
> debugs under DRM_DEBUG_ATOMIC is a bad idea. Let's use DRM_DEBUG_K
https://bugzilla.kernel.org/show_bug.cgi?id=117581
Zhang Rui changed:
What|Removed |Added
Component|Hibernation/Suspend |Video(DRI - non Intel)
Assignee|ru
Hi Dave,
On Tue, 2016-05-10 at 09:51 +, Alexey Brodkin wrote:
> Hi Dave,
>
> On Fri, 2016-04-29 at 11:36 +, Alexey Brodkin wrote:
> >
> > Hi Dave,
> >
> > Please pull this mini-series that allows ARC PGU to use
> > dedicated memory location as framebuffer backing storage.
> >
> > v2 of
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160516/03f5b11d/attachment.html>
[124378.446464] radeon :01:00.0: GPU reset succeeded, trying to resume
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160516/86063652/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160516/85c5f5b0/attachment.html>
Hi Yingjoe,
On Thu, 2016-05-12 at 22:59 +0800, Yingjoe Chen wrote:
> On Thu, 2016-05-12 at 19:49 +0800, yt.shen at mediatek.com wrote:
> > From: YT Shen
> >
> > Add device tree binding documentation for the display subsystem in
> > Mediatek SoC MT2701
> >
> > Signed-off-by: YT Shen
> > ---
> >
ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an
additional DSI RX block that takes in DSI video mode output.
Trying to get this driver merged has had some challenges:
- ADV7533 has an I2C control bus, but acts as a DSI peripheral too.
After discussions, it was concluded th
We don't want to use the old i2c slave encoder interface anymore.
Remove that and make the i2c driver create a drm_bridge entity instead.
Converting to bridges helps because the kms drivers don't need to
exract encoder slave ops from this driver and use it within their
own encoder/connector ops.
When the adv7511 i2c client doesn't have an interrupt line, we observe a
deadlock on caused by trying to lock drm device's mode_config.mutex twice
in the same context.
Here is the sequence that causes it:
ioctl DRM_IOCTL_MODE_GETCONNECTOR from userspace
drm_mode_getconnector (acquires mode_conf
ADV7533 is a DSI to HDMI encoder chip. It is a derivative of ADV7511,
with additional blocks to translate input DSI data to parallel RGB
data. Besides the ADV7511 I2C register map, it has additional registers
that require to be configured to activate the DSI Rx block.
Create a new config that enab
In order to pass DSI specific parameters to the DSI host, we need the
driver to create a mipi_dsi_device DSI device that attaches to the
host.
Use of_graph helpers to get the DSI host DT node. Create a MIPI DSI
device using this host. Finally, attach this device to the DSI host.
Populate DT param
ADV7533 provides an internal timing generator for certain modes that it
can't use the DSI clock directly.
We've observed that HDMI is more stable with the internal timing
generator, especially if there are instabilities in the DSI clock source.
The data spec also seems to recommend the usage of th
Lower modes on ADV7533 require lower number of DSI lanes for correct
operation. If ADV7533 is being used with 4 DSI lanes, then switch the
lanes to 3 when the target mode's pixel clock is less than 80 Mhz.
Based on patch by Andy Green
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/i2c/adv751
Add description of ADV7533. Add the required and optional properties that
are specific to it.
Cc: devicetree at vger.kernel.org
Acked-by: Rob Herring
Signed-off-by: Archit Taneja
---
.../bindings/display/bridge/adi,adv7511.txt| 26 +-
1 file changed, 21 insertions(
Hi CK,
On Fri, 2016-05-13 at 11:59 +0800, CK Hu wrote:
> Hi, YT:
>
> On Thu, 2016-05-12 at 19:49 +0800, yt.shen at mediatek.com wrote:
> > From: YT Shen
> >
> > This patch add support for the Mediatek MT2701 DISP subsystem.
> > There is only one OVL engine in MT2701, and we have shadow
> > regis
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160516/3437d289/attachment.html>
Hi Archit,
On Friday 22 Apr 2016 11:10:18 Archit Taneja wrote:
> On 04/22/2016 04:02 AM, Laurent Pinchart wrote:
> > On Wednesday 09 Mar 2016 16:27:18 Archit Taneja wrote:
> >> Add description of ADV7533. Add the required and optional properties that
> >> are specific to it.
> >>
> >> Cc: devicet
On 13 May 2016 at 16:13, wrote:
> From: Ville Syrjälä
>
> DRM_DEBUG_ATOMIC generates a lot of noise that no one normally cares
> about. However error paths everyone cares about, so hiding thea error
> debugs under DRM_DEBUG_ATOMIC is a bad idea. Let's use DRM_DEBUG_KMS
> for those instead.
>
A
Hi Meng,
On Sun, 15 May 2016 16:34:44 +0800
Meng Yi wrote:
> This driver add the basic functions for Encoder, and link the Encoder to
> appropriate DRM bridge.
> This driver is depend on sii9022 driver(drm_bridge approach),which is
> sent by Boris Brezillon to community but not merged.
> https:/
Hi,
This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.
Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the scree
If simplefb was setup by our bootloader and enabled in the DT, we will have
a first framebuffer loaded in our system.
However, as soon as our DRM driver will load, it will reset the controller,
initialise it and, if the framebuffer emulation is enabled, register a
second framebuffer device.
This
Our RGB bus can be either connected to a bridge or a panel. While the panel
support was already there, the bridge was not.
Fix that.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 4 +--
drivers/gpu/drm/sun4i/sun4i_rgb.c | 56 +++---
driv
Most of the display engine is shared between the R8 and the A13. Move the
common parts to the Ã13 DTSI.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-a13.dtsi | 112
arch/arm/boot/dts/sun5i-r8.dtsi | 120 ++-
2
The TCON channel 0 clock that is the parent clock of our pixel clock is
expected to change its rate depending on the resolution we want to output
in our display engine.
However, since it's only a mux, the only way it can do that is by changing
its parents rate.
Allow to give flags in our display
Our pixel clock currently only tries to deal with the current parent rate.
While that works when the resolution is the same than the one already
program, or when we can compute directly the rate from the current parent
rate, it cannot work in most situation when we want to change the
frequency, an
In case of an error, our pointer to the drm_panel structure attached to our
encoder will hold an error pointer, not a NULL pointer.
Make sure we check the right thing.
Fixes: 29e57fab97fc ("drm: sun4i: Add RGB output")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 +-
1
Enable the new DRM driver in the sunxi default configuration
Signed-off-by: Maxime Ripard
---
arch/arm/configs/sunxi_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index e20ae3925e36..6a1447cf8feb 100644
--- a/a
Now that connector register helpers have been created, switch to them.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 31 ++-
1 file changed, 2 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4
Some boards have an entirely passive RGB to VGA bridge, based on either
DACs or resistor ladders.
Those might or might not have an i2c bus routed to the VGA connector in
order to access the screen EDIDs.
Add a bridge that doesn't do anything but expose the modes available on the
screen, either ba
The RGB bus can be used in several configurations, one of which being the
RGB666.
Add a pinctrl group for that case.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-a13.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot
In the current multiplier base clock implementation, if the
CLK_SET_RATE_PARENT flag isn't set, the code will not make sure that the
multiplier computed remains within the boundaries of our clock.
This means that if the clock we want to reach is below the parent rate,
or if the multiplier is above
get_parent is supposed to return an unsigned 8 bit integer, so returning
-EINVAL is a bad idea.
Remove it.
Reported-by: Dan Carpenter
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi/clk-sun4i-tcon-ch1.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/clk/sunxi/clk-sun4i-tcon-c
Our pixel clock cannot reach a high enough rate for some rather high while
common resolutions (like 1080p60).
Make sure we filter the resolutions we cannot reach in our mode_valid
function.
Fixes: 29e57fab97fc ("drm: sun4i: Add RGB output")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i
Enable the new DRM driver in the multi_v7 defconfig
Signed-off-by: Maxime Ripard
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index f7e0d49b515a..80591f3e867e 100644
--- a/ar
Enable the RGB to VGA bridge driver in the defconfig
Signed-off-by: Maxime Ripard
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 80591f3e867e..5987688dea81 100644
--- a/a
Enable the VGA bridge used on the A13-Olinuxino in the sunxi defconfig
Signed-off-by: Maxime Ripard
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 6a1447cf8feb..3676cc2db2eb 100644
Now that we have support for the VGA bridges using our DRM driver, enable
the display engine for the Olimex A13-Olinuxino.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 34 +++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot
A fixed factor clock, if it needs to change its rate, by definition do not
have any choice but to modify its parent rate.
Add the CLK_SET_RATE_PARENT flag to that clock so that it can happen
Signed-off-by: Maxime Ripard
---
drivers/clk/clk-fixed-factor.c | 3 ++-
1 file changed, 2 insertions(+)
The pixel clock being only a divider of its parent clock, depending on the
resolution, it's expected to change its parent rate. Add that flag so that
the clock framework knows it.
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Maxime Ripard
---
drivers/gpu/d
Our code currently defers our probe on any error, even if we were not
expecting to have one at all.
Make sure we return -EPROBE_DEFER only when we were supposed to have a
panel, but it's not probed yet.
Fixes: 29e57fab97fc ("drm: sun4i: Add RGB output")
Signed-off-by: Maxime Ripard
---
drivers/
On Mon, May 16, 2016 at 2:47 PM, Maxime Ripard
wrote:
> Our RGB bus can be either connected to a bridge or a panel. While the panel
> support was already there, the bridge was not.
>
> Fix that.
>
> Signed-off-by: Maxime Ripard
For bridge support the only thing you need is to set
drm_encoder->br
Hi Maxime,
Thank you for the patch.
On Monday 16 May 2016 14:47:13 Maxime Ripard wrote:
> Some boards have an entirely passive RGB to VGA bridge, based on either
> DACs or resistor ladders.
>
> Those might or might not have an i2c bus routed to the VGA connector in
> order to access the screen E
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160516/23f10d58/attachment.html>
I am seeing the following UBSAN warning on three of my computers (4.6.0
with UBSAN turned on). I am reporting this because some of the UBSAN
reports have been correct (some have been false positives though).
[9.372287]
On Mon, May 16, 2016 at 9:16 AM, Meelis Roos wrote:
> I am seeing the following UBSAN warning on three of my computers (4.6.0
> with UBSAN turned on). I am reporting this because some of the UBSAN
> reports have been correct (some have been false positives though).
Already fixed in drm-next:
http
https://bugzilla.kernel.org/show_bug.cgi?id=112491
--- Comment #18 from Alex Deucher ---
(In reply to Dionisus Torimens from comment #17)
> I think I've solved it.
> The kernel parameter
>
> radeon.runpm=0
>
> seems to work around the issue. The performance is degraded, but the
> temperatures
Add basic support for the sii902x RGB -> HDMI bridge.
This driver does not support audio output yet.
Signed-off-by: Boris Brezillon
Tested-by: Nicolas Ferre
---
Hello,
This patch is only adding basic support for the sii9022 chip.
As stated in the commit log, there's no audio support, but the
dr
Add Sii9022 DT bindings description.
Signed-off-by: Boris Brezillon
---
Changes since v1:
- rename doc file
- s/sil902/sii902/
---
.../devicetree/bindings/display/bridge/sii902x.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/binding
On Mon, May 16, 2016 at 7:47 AM, Maxime Ripard
wrote:
> Some boards have an entirely passive RGB to VGA bridge, based on either
> DACs or resistor ladders.
>
> Those might or might not have an i2c bus routed to the VGA connector in
> order to access the screen EDIDs.
>
> Add a bridge that doesn't
On Mon, May 16, 2016 at 12:58 AM, Heloise NH wrote:
> From: tom will
>
> When the initial value of i is greater than zero,
> it may cause endless loop, resulting in array out
> of bouds, fix it.
>
> Signed-off-by: tom will
Applied to both radeon and amgpu.
Thanks!
Alex
> ---
> drivers/gpu/d
On Sat, May 14, 2016 at 10:03 AM, Emil Velikov
wrote:
> Hi all,
>
> On 13 May 2016 at 19:48, Alex Deucher wrote:
>> From: Eric Huang
>>
>> This implements sclk overdrive(OD) overclocking support for Fiji,
>> and the maximum overdrive percentage is 20.
>>
>> Reviewed-by: Alex Deucher
>> Signed-
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160516/15f7a449/attachment.html>
f bug 93649 ***
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160516/a71bb53d/attachment-0001.html>
vel/attachments/20160516/fee1e81f/attachment-0001.html>
On Fri, May 13, 2016 at 11:06:40PM +0530, Muhammad Falak R Wani wrote:
> It is preferred to use ARRAY_SIZE() for size calculation, instead
> using sizeof(array)/sizeof(*array). It makes the code more readable.
>
> Signed-off-by: Muhammad Falak R Wani
Reviewed-by: Eric Engestrom
Thanks, and sor
On Fri, May 13, 2016 at 1:36 PM, Muhammad Falak R Wani
wrote:
> It is preferred to use ARRAY_SIZE() for size calculation, instead
> using sizeof(array)/sizeof(*array). It makes the code more readable.
>
> Signed-off-by: Muhammad Falak R Wani
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/
-DragonFly-like-Linux.patch
Type: text/x-patch
Size: 1002 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160516/93cc8e27/attachment.bin>
On Mon, May 16, 2016 at 04:04:29PM +0200, Boris Brezillon wrote:
> Add Sii9022 DT bindings description.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes since v1:
> - rename doc file
> - s/sil902/sii902/
> ---
> .../devicetree/bindings/display/bridge/sii902x.txt | 35
> ++
https://bugzilla.kernel.org/show_bug.cgi?id=113021
Len Brown changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
On 16 May 2016 at 17:24, Francois Tigeot wrote:
> Hi Emil,
>
> Emil Velikov wrote:
>>
>>
>> On 14 May 2016 at 08:13, François Tigeot wrote:
>>>
>>> The drm code in DragonFly uses a local Linux implementation which doesn't
>>> define the __linux__ macro.
>>>
>>> Use __DragonFly__ instead in order
On 16 May 2016 at 15:42, Alex Deucher wrote:
> On Sat, May 14, 2016 at 10:03 AM, Emil Velikov
> wrote:
>> Hi all,
>>
>> On 13 May 2016 at 19:48, Alex Deucher wrote:
>>> From: Eric Huang
>>>
>>> This implements sclk overdrive(OD) overclocking support for Fiji,
>>> and the maximum overdrive perc
Hi Chris,
On 9 May 2016 at 11:04, Chris Wilson wrote:
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -607,12 +606,8 @@ drm_gem_object_lookup(struct drm_device *dev, struct
> drm_file *filp,
>
> /* Check if we currently have a reference on the object */
>
On Mon, May 16, 2016 at 6:04 PM, Emil Velikov
wrote:
> On 16 May 2016 at 15:42, Alex Deucher wrote:
>> On Sat, May 14, 2016 at 10:03 AM, Emil Velikov
>> wrote:
>>> Hi all,
>>>
>>> On 13 May 2016 at 19:48, Alex Deucher wrote:
From: Eric Huang
This implements sclk overdrive(OD)
Hi Benjamin,
I'd suspect you're interested in some feedback on these, so here is a few :-)
Sadly (ideally?) nothing serious, but a bunch minor suggestions, plus
the odd bug.
On 9 May 2016 at 16:07, Benjamin Gaignard
wrote:
> --- /dev/null
> +++ b/drivers/smaf/smaf-core.c
> @@ -0,0 +1,794 @@
>
lists.freedesktop.org/archives/dri-devel/attachments/20160516/7ebba85c/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160516/05613835/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160516/cb6f7818/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160516/fc8076ad/attachment.html>
On Tue, 17 May 2016, Francois Tigeot wrote:
>
>>> On the other hand, the non-Linux code path really is unused. I didn't want
>>> to be too intrusive in my patch but it's probably best to just remove it.
>>>
>> There is more to this world than Linux and BSD, there's Solaris as
>> well. Even though
Add missing DisplayPort downstream port types. The introduced
new port types are DP++ and Wireless.
Signed-off-by: Mika Kahola
---
include/drm/drm_dp_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 92d9a52..4049af9 10
Read from DPCD receiver capability field for the following
features:
- max TMDS clock rate
- max bits per component
- single or dual link support
- high color depth support
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 5 +
include/drm/drm_dp_helper.h | 14 +++
Hi Boris,
On Monday, May 16, 2016 8:45 PM
Boris Brezillon wrote:
>
> Hi Meng,
>
> On Sun, 15 May 2016 16:34:44 +0800
> Meng Yi wrote:
>
> > This driver add the basic functions for Encoder, and link the Encoder
> > to appropriate DRM bridge.
> > This driver is depend on sii9022 driver(drm_bri
On Mon, May 16, 2016 at 8:47 PM, Maxime Ripard
wrote:
> Enable the new DRM driver in the sunxi default configuration
>
> Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
Prep work for DP branch device handling
This series of patches reads DPCD register 0x80h for receiver
capabilities for DP branch devices. The branch device types are
converters for the following standards
- DP to VGA
- DP to DVI
- DP to HDMI
- DP++ dual mode
- Wireless WiGig
DPCD register d
Read from DPCD receiver capability field the max allowed
pixel clock and bits per component for DP to VGA converter.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 46
drivers/gpu/drm/i915/intel_drv.h | 2 ++
include/drm/drm_dp_helper.
Read from DPCD receiver capability field for DP to HDMI
converter. The features for DP to HDMI converter are
- max TMDS characther clock rate
- max bits per component
- support for conversion from 3D frame sequential to frame pack
- support for YCBCR422 pass through
- support for YCBCR420 pas
Read from DPCD receiver capability field for the
DP++ devices. The features are
- max TMDS charachter clock
- max bits per component
- support for conversion from 3D frame sequential to
frame pack
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 4
include/drm/drm_dp
Read from DPCD receiver capability field for the
DP to Wireless converter. The only supported wireless
technology on DP1.3 spec is WiGig display extension. If WiGig
display extension is present, then read out the
- number of wde tx on device
- the number of wde txs that can be concurrently activ
Prep work to improve DP branch device handling.
Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.
The register defines the pixel rat
Hi Emil,
These values are just for this clip using on this test.
We have given method in both kernel and mesa codes on how to calculate dpb size
and context size. I calculated them from the sample clip and used only for this
test.
Regards,
Sonny
From: Em
Hi,
On Mon, May 16, 2016 at 8:47 PM, Maxime Ripard
wrote:
> The TCON channel 0 clock that is the parent clock of our pixel clock is
> expected to change its rate depending on the resolution we want to output
> in our display engine.
>
> However, since it's only a mux, the only way it can do that
Thanks for your catch, Nils.
On 16-05-14 02:27 AM, Nils Wallménius wrote:
> Hi Eric,
>
> A little nitpick below.
>
> Regards
> Nils
>
> On Fri, May 13, 2016 at 8:48 PM, Alex Deucher
> wrote:
>
>> From: Eric Huang
>>
>> Add a new sysfs entry pp_sclk_od to support sclk overdrive(OD)
>> overclock
Hi,
I'm observing a soft lockup issue w/ the ASPEED controller on an
arm64 server platform. This was originally seen on Ubuntu's 4.4
kernel, but it is reproducible w/ vanilla 4.6-rc7 as well.
[ 32.792656] NMI watchdog: BUG: soft lockup - CPU#38 stuck for 22s!
[swapper/38:0]
I observe this just
85 matches
Mail list logo
