On 14.12.2022 06:33, Jagan Teki wrote:
> On Tue, Dec 13, 2022 at 9:11 PM Marek Szyprowski
> wrote:
>> On 13.12.2022 16:15, Jagan Teki wrote:
>>> On Tue, Dec 13, 2022 at 8:24 PM Marek Szyprowski
>>> wrote:
On 13.12.2022 15:18, Jagan Teki wrote:
> On Tue, Dec 13, 2022 at 7:31 PM Marek Szyp
Am 13.12.22 um 21:14 schrieb Linus Torvalds:
On Mon, Dec 12, 2022 at 6:56 PM Dave Airlie wrote:
There are a bunch of conflicts, one in amdgpu is a bit nasty, I've
cc'ed Christian/Alex to make sure they know to check whatever
resolution you find. The one I have is what we have in drm-tip tree.
On Wed, Dec 14, 2022 at 1:34 PM Marek Szyprowski
wrote:
>
> On 14.12.2022 06:33, Jagan Teki wrote:
> > On Tue, Dec 13, 2022 at 9:11 PM Marek Szyprowski
> > wrote:
> >> On 13.12.2022 16:15, Jagan Teki wrote:
> >>> On Tue, Dec 13, 2022 at 8:24 PM Marek Szyprowski
> >>> wrote:
> On 13.12.2022
On Wed, Dec 14, 2022 at 10:54:14AM +0800, Jiasheng Jiang wrote:
> Add the check for the return value of dma_alloc_coherent in order to
> avoid NULL pointer dereference.
>
> This flaw was found using an experimental static analysis tool we are
> developing, APP-Miner, which has not been disclosed.
On 2022-12-14 01:02:14, Konrad Dybcio wrote:
>
>
> On 14.12.2022 00:22, Marijn Suijten wrote:
> > According to downstream /and the comment copied from it/ this comparison
> > should be the other way around. In other words, when the panel driver
> > requests to use more slices per packet than wha
On 12.12.22 19:29, Jagan Teki wrote:
> Enable the drm panel prepare_prev_first flag so-that the previous
> controller should be prepared first before the prepare for the
> panel is called.
>
> samsung-s6e3ha2, samsung-s6e63j0x03 and samsung-s6e8aa0 are the
> effected samsung-s6e panels for this
On 12.12.22 19:29, Jagan Teki wrote:
> From: Marek Szyprowski
>
> Enable the drm bridge pre_enable_prev_first flag so that the
> previous bridge pre_enable should be called first before the
> pre_enable for the tc358764 bridge is called.
>
> This makes sure that the previous bridge should be ini
On 12.12.22 19:29, Jagan Teki wrote:
> Restore the proper bridge chain by finding the previous bridge
> in the chain instead of passing NULL.
>
> This establishes a proper bridge chain while attaching downstream
> bridges.
>
> Reviewed-by: Marek Vasut
> Signed-off-by: Marek Szyprowski
> Signed-
On Tue, 13 Dec 2022 11:32:01 -0500
Harry Wentland wrote:
> On 12/13/22 05:23, Pekka Paalanen wrote:
> > On Mon, 12 Dec 2022 13:21:27 -0500
> > Harry Wentland wrote:
> >
> >> Drivers might not support all colorspaces defined in
> >> dp_colorspaces and hdmi_colorspaces. This results in
> >> und
On Tue, 13 Dec 2022 11:41:08 -0500
Harry Wentland wrote:
> On 12/13/22 05:39, Pekka Paalanen wrote:
> > On Mon, 12 Dec 2022 13:21:25 -0500
> > Harry Wentland wrote:
> >
> >> This allows us to use strongly typed arguments.
> >>
> >> Signed-off-by: Harry Wentland
> >> Cc: Pekka Paalanen
> >>
On Tue, 13 Dec 2022 18:20:59 +0100
Michel Dänzer wrote:
> On 12/12/22 19:21, Harry Wentland wrote:
> > This will let us pass kms_hdr.bpc_switch.
> >
> > I don't see any good reasons why we still need to
> > limit bpc to 8 bpc and doing so is problematic when
> > we enable HDR.
> >
> > If I reme
On 12.12.22 15:57, Jagan Teki wrote:
> HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> 0 = Enable and 1 = Disable.
>
> The logic for checking these mode flags was correct before
> the MIPI_DSI*_NO_* mode flag conversion.
>
> This patch is trying to fix this MIPI_DSI*_NO_* mode flags h
On 12.12.22 15:57, Jagan Teki wrote:
> HSA/HBP/HFP/HSE mode bits in Processor Reference Manuals specify
> a naming conversion as 'disable mode bit' due to its bit definition,
> 0 = Enable and 1 = Disable.
>
> For HSE bit, the i.MX 8M Mini/Nano/Plus Applications Processor
> Reference Manual named t
On 13.12.2022 16:22, Tvrtko Ursulin wrote:
On 13/12/2022 14:52, Andrzej Hajda wrote:
On 13.12.2022 13:39, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values
grew, the
code become a bit unsightly. Consolidate by storing the required
v
14 декабря 2022 г. 00:11:58 GMT+02:00, Dmitry Baryshkov
пишет:
>
>
>On 13 December 2022 23:53:48 EET, Abhinav Kumar
>wrote:
>>
>>
>>On 12/1/2022 11:54 AM, Dmitry Baryshkov wrote:
>>> On 30/11/2022 22:09, Adam Skladowski wrote:
>>
>>>
>>> We will pick this into msm-fixes during the next cycle.
https://bugzilla.kernel.org/show_bug.cgi?id=216806
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |NEEDINFO
--
You may
Changes in v2:
- Use dp bridge to set psr entry/exit instead of dpu_enocder.
- Don't modify whitespaces.
- Set self refresh aware from atomic_check.
- Set self refresh aware only if psr is supported.
- Provide a stub for msm_dp_display_set_psr.
- Move dp functions to bridge code.
Chang
Update crtc retrieval from dpu_enc to dpu_enc connector state,
since new links get set as part of the dpu enc virt mode set.
The dpu_enc->crtc cache is no more needed, hence cleaning it as
part of this change.
This patch is dependent on the series:
https://patchwork.freedesktop.org/series/110969/
Add new helper functions, drm_atomic_get_old_crtc_for_encoder
and drm_atomic_get_new_crtc_for_encoder to retrieve the
corresponding crtc for the encoder.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Douglas Anderson
---
drivers/gpu/drm/drm_atomic.c | 60 ++
Use atomic variants for DP bridge callback functions so that
the atomic state can be accessed in the interface drivers.
The atomic state will help the driver find out if the display
is in self refresh state.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Ba
The eDP and DP interfaces shared the bridge operations and
the eDP specific changes were implemented under is_edp check.
To add psr support for eDP, we started using a new set of eDP
bridge ops. We are moving the eDP specific code in the
dp_bridge_mode_valid function to a new eDP function,
edp_brid
Add support for basic panel self refresh (PSR) feature for eDP.
Add a new interface to set PSR state in the sink from DPU.
Program the eDP controller to issue PSR enter and exit SDP to
the sink.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
From: Sankeerth Billakanti
Updated frames get queued if self_refresh_aware is set when the
sink is in psr. To support bridge enable and avoid queuing of update
frames, reset the self_refresh_aware state after entering psr.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
---
Use atomic variants for panel bridge callback functions such that
certain states like self-refresh can be accessed as part of
enable/disable sequence.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/panel.c | 20 +++
This change will handle the psr entry exit cases in the panel
bridge atomic callback functions. For example, the panel power
should not turn off if the panel is entering psr.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/bridge/panel.c | 48 ++
Hi Mark,
Thanks for your report!
On Tue, Dec 13, 2022 at 5:58 PM Mark Brown wrote:
> On Tue, Dec 13, 2022 at 05:56:30AM -0800, KernelCI bot wrote:
> The KernelCI bisection bot found regressions in at least two KMS tests
> in the Renesas tree on rk3399-gru-kevin just after the Renesas tree
> merg
Use atomic variants for encoder callback functions such that
certain states like self-refresh can be accessed as part of
enable/disable sequence.
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10 ++-
According to KMS documentation, The driver must not release any shared
resources if active is set to false but enable still true.
Fixes: ccc862b957c6 ("drm/msm/dpu: Fix reservation failures in modeset")
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu
Enable PSR on eDP interface using drm self-refresh librabry.
This patch uses a trigger from self-refresh library to enter/exit
into PSR, when there are no updates from framework.
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dis
Recommended way of reading the interface timing gen status is via
status register. Timing gen status register will give a reliable status
of the interface especially during ON/OFF transitions. This support was
added from DPU version 5.0.0.
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/di
There can be a race between timing gen disable and vblank irq. The
wait post timing gen disable may return early but intf disable sequence
might not be completed. Ensure that, intf status is disabled before
we retire the function.
Signed-off-by: Vinod Polimera
---
.../gpu/drm/msm/disp/dpu1/dpu_e
Reset the datapath after disabling the timing gen, such that
it can start on a clean slate when the intf is enabled back.
This was a recommended sequence from the DPU HW programming guide.
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 1 +
1 file change
Clear interface active register from the datapath for a clean shutdown of
the datapath.
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu
Changes since v1:
fixed the dt-bindings maintainer email adress
dropped backlight, port, power-supply and reset-gpios as they're
provided by panel-common.yaml as pointed by Krzysztof Kozlowski
changed reg: true to reg : maxItems: 1
Christophe Branchereau (2):
drm/panel: add the orisetech
Add bindings for the Forcaltech gpt3, which is a 640x480 3.0" 4:3
IPS LCD Panel found in the YLM/Anbernic RG300X handheld.
Signed-off-by: Christophe Branchereau
---
.../display/panel/focaltech,gpt3.yaml | 56 +++
1 file changed, 56 insertions(+)
create mode 100644
Docum
Add the orisetech ota5601a ic driver
For now it only supports the focaltech gpt3 3" 640x480 ips panel
found in the ylm rg300x handheld.
Signed-off-by: Christophe Branchereau
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu
Wrong cover title, should be "Add support for the orisetech ota5601" sorry...
On Wed, Dec 14, 2022 at 12:00 PM Christophe Branchereau
wrote:
>
> Changes since v1:
> fixed the dt-bindings maintainer email adress
>
> dropped backlight, port, power-supply and reset-gpios as they're
> provided by
On 14/12/2022 12:00, Christophe Branchereau wrote:
> Add bindings for the Forcaltech gpt3, which is a 640x480 3.0" 4:3
> IPS LCD Panel found in the YLM/Anbernic RG300X handheld.
>
> Signed-off-by: Christophe Branchereau
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Changes since v1:
reworked the dt-bindings to add a spi node, dropped properties already
present in panel-common.yaml
Christophe Branchereau (1):
drm/panel: Add driver for the AUO A030JTN01 TFT LCD
Paul Cercueil (1):
dt-bindings: display/panel: Add AUO A030JTN01
.../bindings/display/pane
Add driver for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
interface.
Signed-off-by: Christophe Branchereau
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Make
From: Paul Cercueil
Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
interface.
Signed-off-by: Paul Cercueil
Signed-off-by: Christophe Branchereau
---
.../bindings/display/panel/auo,a030jtn01.yaml | 61 +
From: Marian Cichy
Add support for the LCD Controller found on i.MX21 and i.MX25.
It targets to be a drop in replacement for the imx-fb driver.
Signed-off-by: Marian Cichy
[ukl: Rebase to v6.1, various smaller fixes]
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/imx/Kconfig| 7 +
Hello,
Compared to (implicit) v1[1] the device tree binding should be good
enough now to pass the dts linters.
As before, Marian Cichy is the declared author of the driver, but he
left Pengutronix, so the email address doesn't work any more.
This is based on top of v6.1 + 93266da2409b ("dt-bindi
Modify the existing (fb-like) binding to support the drm-like binding in
parallel.
Signed-off-by: Uwe Kleine-König
---
.../bindings/display/imx/fsl,imx-lcdc.yaml| 45 ++-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/i
On Mon, Dec 12, 2022 at 03:35:20PM +0100, Jason A. Donenfeld wrote:
> Please CC me on future revisions.
>
> As of 6.2, the prandom namespace is *only* for predictable randomness.
> There's no need to rename anything. So nack on this patch 1/5.
It is not obvious (for casual developers like me) tha
Hi Mark,
Maybe you could retrieve the original thread and rely to it with
the report? That's the ideal way of following up on a patch I
think. You can get the mbox file this way:
./kci_bisect get_mbox \
--commit ca871659ec1606d33b1e76de8d4cf924cf627e34 \
--kdir ~/src/linux
On 14/12/2022 1
Hi,
This patchset adds a few cleanups to the IT66121 HDMI chip driver, and
most importantly adds support for the IT6610 chip.
The driver was tested with both chips, but as I only own a HDMI monitor
without speakers, HDMI audio may not be working on the IT6610.
Cheers,
-Paul
Paul Cercueil (10):
Add a new ite,it6610 compatible string to the IT66121 binding
documentation, since the two chips are very similar.
Signed-off-by: Paul Cercueil
---
.../devicetree/bindings/display/bridge/ite,it66121.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/d
Use regmap_noinc_read() instead of reading the data from the DDC FIFO one
byte at a time.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/bridge/ite-it66121.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c
b/drivers/gpu/dr
Simplify the code of the driver by using
devm_regulator_bulk_get_enable(), which will handle powering up the
regulators, and disabling them on probe error or module removal.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/bridge/ite-it66121.c | 34 +++-
1 file changed, 8
Since all AVI infoframe registers are contiguous in the address space,
the AVI infoframe can be written in one go with regmap_bulk_write().
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/bridge/ite-it66121.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
di
The function it66121_wait_ddc_ready() would previously read the status
register until "true", which means it never actually polled anything and
would just read the register once.
Now, it will properly wait until the DDC hardware is ready or until it
reported an error.
The 'busy' variable was also
This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.
The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
Patch 0001 - 0004: adding devm_drm_of_dsi_get_bridge
Patch 0005 - 0006: optional PHY, PMS_P offset
Patch 0007 :
The DDC error IRQs will fire on the IT6610 every time the FIFO is empty,
which is not very helpful. To resolve this, we can simply disable them,
and handle DDC errors in it66121_wait_ddc_ready().
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/bridge/ite-it66121.c | 49 ++---
The DDC preamble and target address only need to be set once before
reading the EDID, even if multiple segments have to be read.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/bridge/ite-it66121.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git
The DDC FIFO was cleared before the loop in it66121_get_edid_block(),
and at the beginning of each iteration; which means that it did not have
to be cleared before the loop.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/bridge/ite-it66121.c | 16
1 file changed, 16 deletions(
devm_drm_of_dsi_get_bridge is capable of looking up the downstream
DSI bridge and panel and trying to add a panel bridge if the panel
is found.
Replace explicit finding calls with devm_drm_of_dsi_get_bridge.
Signed-off-by: Jagan Teki
---
Changes for v10:
- new patch
drivers/gpu/drm/exynos/exyn
Exynos DSI already converted into a bridge driver, so bridge
detach will suppose happened during bridge chain removal done
by the bridge core.
Drop the explicit call chain to detach the bridge.
Signed-off-by: Jagan Teki
---
Changes for v10:
- new patch
drivers/gpu/drm/exynos/exynos_drm_dsi.c |
Devices can also be child nodes when we also control that device
through the upstream device (ie, MIPI-DCS for a MIPI-DSI device).
Unlike the drm_of_find_panel_or_bridge helper it requires a special
case to lookup a child node of the given parent that isn't either
port or ports.
Lookup for a chil
Add devm OF helper to return the next DSI bridge in the chain.
Unlike general bridge return helper devm_drm_of_get_bridge, this
helper uses the dsi specific panel_or_bridge helper to find the
next DSI device in the pipeline.
Helper lookup a given child DSI node or a DT node's port and
endpoint nu
The same Samsung MIPI DSIM master can also be used in NXP's
i.MX8M Mini/Nano/Plus SoC.
In i.MX8M Mini/Nano/Plus SoC the DSI Phy requires a MIPI DPHY
bit to reset in order to activate the PHY and that can be done
via upstream i.MX8M blk-ctrl driver.
So, mark the phy get as optional.
Reviewed-by:
Samsung MIPI DSIM controller is common DSI IP that can be used
in various SoCs like Exynos, i.MX8M Mini/Nano/Plus.
Add hw_type enum via platform_data so that accessing the different
controller data between various platforms becomes easy and meaningful.
Suggested-by: Marek Szyprowski
Signed-off-b
Look like PLL PMS_P offset value varies between platforms that have
Samsung DSIM IP.
However, there is no clear evidence for it as both Exynos and i.MX
8M Mini Application Processor Reference Manual is still referring
the PMS_P offset as 13.
The offset 13 is not working for i.MX8M Mini SoCs but t
From: Marek Szyprowski
Host transfer() in the DSI master will invoke only when the DSI commands
are sent from DSI devices like DSI Panel or DSI bridges and this host
the transfer wouldn't invoke for I2C-based-DSI bridge drivers.
Handling DSI host initialization in transfer calls misses the contr
LCDIF-DSIM glue logic inverts the HS/VS/DE signals and expecting
the i.MX8M Mini/Nano DSI host to add additional Data Enable signal
active low (DE_LOW). This makes the valid data transfer on each
horizontal line.
So, add additional bus flags DE_LOW setting via input_bus_flags
for i.MX8M Mini/Nano
DSI host registration, attach and detach operations are quite
different for the component and bridge-based DRM drivers.
Supporting generic bridge driver to use both component and bridge
based DRM drivers can be tricky and would require additional host
related operation hooks.
Add host operation
Look like an explicit fixing up of mode_flags is required for DSIM IP
present in i.MX8M Mini/Nano SoCs.
At least the LCDIF + DSIM needs active low sync polarities in order
to correlate the correct sync flags of the surrounding components in
the chain to make sure the whole pipeline can work proper
Finding the right input bus format throughout the pipeline is hard
so add atomic_get_input_bus_fmts callback and initialize with the
proper input format from list of supported output formats.
This format can be used in pipeline for negotiating bus format between
the DSI-end of this bridge and the
Enable and disable of te_gpio's are Exynos platform specific
irq handling, so add the exynos based irq operations and hook
them for exynos plat_data.
Signed-off-by: Jagan Teki
---
Changes for v10:
- split from previous series patch
"drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM br
This will make it easier later to introduce support for new chips in
this driver.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/bridge/ite-it66121.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c
b/driver
Samsung MIPI DSIM bridge can also be found in i.MX8M Plus SoC.
Add dt-bingings for it.
Cc: devicet...@vger.kernel.org
Cc: Rob Herring
Signed-off-by: Jagan Teki
---
Changes for v10, v9:
- none
Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
1 file changed, 1 insertion(+
Samsung MIPI DSIM bridge can also be found in i.MX8M Mini/Nano SoC.
Add dt-bingings for it.
Cc: devicet...@vger.kernel.org
Acked-by: Rob Herring
Signed-off-by: Jagan Teki
---
Changes for v10, v9:
- none
Changes for v8:
- add comment to include i.MX8M Nano.
Changes for v7, v6, v5, v4:
- none
Cha
Add support for the IT6610 HDMI encoder.
The hardware is very similar, and therefore the driver did not require
too many changes. Some bits are only available on the IT66121, and
vice-versa. Also, the IT6610 requires specific polarities on the DE and
pixel lines.
Signed-off-by: Paul Cercueil
---
Samsung MIPI DSIM master can also be found in i.MX8M Mini/Nano SoC.
Add compatible and associated driver_data for it.
Reviewed-by: Laurent Pinchart
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
Changes for v10, v9:
- none
Changed for v8:
- fix and update the comment
Changes for
Samsung MIPI DSIM controller is common DSI IP that can be used in various
SoCs like Exynos, i.MX8M Mini/Nano.
In order to access this DSI controller between various platform SoCs,
the ideal way to incorporate this in the drm stack is via the drm bridge
driver.
We already have a consolidated code
From: Marek Vasut
Add extras to support i.MX8M Plus. The main change is the removal of
HS/VS/DE signal inversion in the LCDIFv3-DSIM glue logic, otherwise
the implementation of this IP in i.MX8M Plus is very much compatible
with the i.MX8M Mini/Nano one.
Signed-off-by: Marek Vasut
Signed-off-by
On Wed, Dec 14, 2022 at 01:55:03PM +0100, Guillaume Tucker wrote:
> Maybe you could retrieve the original thread and rely to it with
> the report? That's the ideal way of following up on a patch I
> think. You can get the mbox file this way:
> ./kci_bisect get_mbox \
> --commit ca871659ec1606
On Thu, Dec 8, 2022 at 1:08 PM Jacek Lawrynowicz
wrote:
> +
> +static inline int ivpu_hw_info_init(struct ivpu_device *vdev)
> +{
> + return vdev->hw->ops->info_init(vdev);
> +};
> +
> +static inline int ivpu_hw_power_up(struct ivpu_device *vdev)
> +{
> + ivpu_dbg(vdev, PM, "HW power u
Hi Guillaume,
On Wed, Dec 14, 2022 at 1:54 PM Guillaume Tucker
wrote:
> On 14/12/2022 11:06, Geert Uytterhoeven wrote:
> > On Tue, Dec 13, 2022 at 5:58 PM Mark Brown wrote:
> >> On Tue, Dec 13, 2022 at 05:56:30AM -0800, KernelCI bot wrote:
> >> The KernelCI bisection bot found regressions in at
On 14/12/2022 15:03, Geert Uytterhoeven wrote:
> Hi Guillaume,
>
> On Wed, Dec 14, 2022 at 1:54 PM Guillaume Tucker
> wrote:
>> On 14/12/2022 11:06, Geert Uytterhoeven wrote:
>>> On Tue, Dec 13, 2022 at 5:58 PM Mark Brown wrote:
On Tue, Dec 13, 2022 at 05:56:30AM -0800, KernelCI bot wrote:
On 14/12/2022 14:50, Mark Brown wrote:
> On Wed, Dec 14, 2022 at 01:55:03PM +0100, Guillaume Tucker wrote:
>
>> Maybe you could retrieve the original thread and rely to it with
>> the report? That's the ideal way of following up on a patch I
>> think. You can get the mbox file this way:
>
>> ./
Den 01.12.2022 17.02, skrev Otto Pflüger:
> As stated in
> Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yml,
> the MIPI DBI specification defines two power supplies, one for powering
> the panel and one for the I/O voltage. The panel-mipi-dbi driver
> currently only suppor
On Wed, Dec 14, 2022 at 03:16:33PM +0100, Guillaume Tucker wrote:
> Mark, how did you get the list of recipients?
> There's a command for this btw, which was used when the reports
> were automatically sent to the recipients before we reverted to
> manual filtering to reduce the noise:
My standar
On Wed, Dec 14, 2022 at 03:27:56PM +0100, Guillaume Tucker wrote:
> On 14/12/2022 14:50, Mark Brown wrote:
> > As a developer I tend to find this unhelpful, it makes it much more
> > likely that the mail will get missed. As a reporter it means there's
> > more information to copy into the report.
Hi Mark,
On Wed, Dec 14, 2022 at 3:39 PM Mark Brown wrote:
> On Wed, Dec 14, 2022 at 03:16:33PM +0100, Guillaume Tucker wrote:
> > Mark, how did you get the list of recipients?
>
> > There's a command for this btw, which was used when the reports
> > were automatically sent to the recipients befo
https://bugzilla.kernel.org/show_bug.cgi?id=216806
--- Comment #2 from Balazs Vinarz (viniba...@gmail.com) ---
Hello Alex,
it's set:
$ zgrep DRM_FBDEV /proc/config.gz
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
I just got a hint to use the iommu=pt, but that one didn't work too.
Hi Guillaume,
On Wed, Dec 14, 2022 at 3:16 PM Guillaume Tucker
wrote:
> On 14/12/2022 15:03, Geert Uytterhoeven wrote:
> > On Wed, Dec 14, 2022 at 1:54 PM Guillaume Tucker
> > wrote:
> >> On 14/12/2022 11:06, Geert Uytterhoeven wrote:
> >>> On Tue, Dec 13, 2022 at 5:58 PM Mark Brown wrote:
> >>
On 12/14/2022 6:57 AM, Oded Gabbay wrote:
On Thu, Dec 8, 2022 at 1:08 PM Jacek Lawrynowicz
wrote:
+
+static inline int ivpu_hw_info_init(struct ivpu_device *vdev)
+{
+ return vdev->hw->ops->info_init(vdev);
+};
+
+static inline int ivpu_hw_power_up(struct ivpu_device *vdev)
+{
+ ivp
https://bugzilla.kernel.org/show_bug.cgi?id=216806
--- Comment #3 from Balazs Vinarz (viniba...@gmail.com) ---
It looks like this: https://www.youtube.com/watch?v=8oUUBjmo0_I
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of t
On Wed, Dec 14, 2022 at 1:34 PM Stanislaw Gruszka
wrote:
>
> On Mon, Dec 12, 2022 at 03:35:20PM +0100, Jason A. Donenfeld wrote:
> > Please CC me on future revisions.
> >
> > As of 6.2, the prandom namespace is *only* for predictable randomness.
> > There's no need to rename anything. So nack on t
On 14/12/2022 12:05, Vinod Polimera wrote:
Update crtc retrieval from dpu_enc to dpu_enc connector state,
since new links get set as part of the dpu enc virt mode set.
The dpu_enc->crtc cache is no more needed, hence cleaning it as
part of this change.
This patch is dependent on the series:
http
On Wed, Dec 14, 2022 at 03:57:54PM +0200, Oded Gabbay wrote:
> On Thu, Dec 8, 2022 at 1:08 PM Jacek Lawrynowicz
> wrote:
> > +
> > +static inline int ivpu_hw_info_init(struct ivpu_device *vdev)
> > +{
> > + return vdev->hw->ops->info_init(vdev);
> > +};
> > +
> > +static inline int ivpu_hw_p
On Wed, Dec 14, 2022 at 4:01 AM Pekka Paalanen wrote:
>
> On Tue, 13 Dec 2022 18:20:59 +0100
> Michel Dänzer wrote:
>
> > On 12/12/22 19:21, Harry Wentland wrote:
> > > This will let us pass kms_hdr.bpc_switch.
> > >
> > > I don't see any good reasons why we still need to
> > > limit bpc to 8 bpc
On Wed, Dec 14, 2022 at 04:15:49PM +0100, Eric Dumazet wrote:
> On Wed, Dec 14, 2022 at 1:34 PM Stanislaw Gruszka
> wrote:
> > On Mon, Dec 12, 2022 at 03:35:20PM +0100, Jason A. Donenfeld wrote:
> > > Please CC me on future revisions.
> > >
> > > As of 6.2, the prandom namespace is *only* for pred
On Wed, Dec 14, 2022 at 05:53:52PM +0200, Andy Shevchenko wrote:
> On Wed, Dec 14, 2022 at 04:15:49PM +0100, Eric Dumazet wrote:
> > On Wed, Dec 14, 2022 at 1:34 PM Stanislaw Gruszka
> > wrote:
> > > On Mon, Dec 12, 2022 at 03:35:20PM +0100, Jason A. Donenfeld wrote:
> > > > Please CC me on future
On Tue, Dec 13, 2022 at 02:56:18PM -0800, Kuogee Hsieh wrote:
> Add both data-lanes and link-frequencies property into endpoint
>
> Changes in v7:
> -- split yaml out of dtsi patch
> -- link-frequencies from link rate to symbol rate
> -- deprecation of old data-lanes property
>
> Changes in v8:
>
On Wed, Dec 14, 2022 at 04:15:49PM +0100, Eric Dumazet wrote:
> On Wed, Dec 14, 2022 at 1:34 PM Stanislaw Gruszka
> wrote:
> >
> > On Mon, Dec 12, 2022 at 03:35:20PM +0100, Jason A. Donenfeld wrote:
> > > Please CC me on future revisions.
> > >
> > > As of 6.2, the prandom namespace is *only* for
On Tue, 15 Nov 2022 19:27:20 +0800, Pin-yen Lin wrote:
> Add caching when EDID is read, and invalidate the cache until the
> bridge detects HPD low or sink count changes on HPD_IRQ.
>
> It takes 1.2s for IT6505 bridge to read a 3-block EDID, and skipping
> one EDID read would be a notable differen
On Wed, Dec 14, 2022 at 12:05 AM Christian König
wrote:
>
> Anyway we need to re-apply b09d6acba1d9 which should be trivial.
Note that my resolution did exactly that (*), it's just that when I
double-checked against Dave's suggested merge that I noticed I'd done
things differently than he did.
(
On Tue, Dec 13, 2022 at 03:41:19PM -0800, Matt Roper wrote:
> Programming of the ENABLE_PREFETCH_INTO_IC bit originally showed up in
> both the general DG2 tuning guide (applicable to all DG2
> variants/steppings) and under Wa_22012654132 (applicable only to
> specific steppings). It has now been
1 - 100 of 147 matches
Mail list logo
