On Sun, 2024-03-03 at 17:42 +, Jonathan Cameron wrote:
> On Fri, 23 Feb 2024 13:13:58 +0100
> Nuno Sa wrote:
>
> > Hi Jonathan, likely you're wondering why I'm sending v7. Well, to be
> > honest, we're hoping to get this merged this for the 6.9 merge window.
> > Main reason is because the
On 04/03/2024 06:36, Dharma Balasubiramani wrote:
> Convert the atmel,lcdc bindings to DT schema.
> Changes during conversion: add missing clocks and clock-names properties.
>
> Signed-off-by: Dharma Balasubiramani
> ---
> This patch converts the existing lcdc display text binding to JSON
The Allwinner A64's GPU has currently three operating points. However,
the BSP runs the GPU fixed at 432 MHz. In addition, at least one of the
devices using that SoC - the pinephone - shows unstabilities (see link)
that can be circumvented by running the GPU at a fixed rate.
Therefore, remove the
The Allwinner A64 manual lists the following constraints for the
PLL-MIPI clock:
- M/N <= 3
- (PLL_VIDEO0)/M >= 24MHz
Use these constraints.
Reviewed-by: Jernej Skrabec
Signed-off-by: Frank Oltmanns
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 12 +++-
1 file changed, 7
The Allwinner A64 manual lists the following constraints for the
PLL-MIPI clock:
- M/N <= 3
- (PLL_VIDEO0)/M >= 24MHz
The PLL-MIPI clock is implemented as ccu_nkm. Therefore, add support for
these constraints.
Reviewed-by: Jernej Skrabec
Signed-off-by: Frank Oltmanns
---
When the Allwinner A64's TCON0 searches the ideal rate for the connected
panel, it may happen that it requests a rate from its parent PLL-MIPI
which PLL-MIPI does not support.
This happens for example on the Olimex TERES-I laptop where TCON0
requests PLL-MIPI to change to a rate of several GHz
The Allwinner SoC's typically have an upper and lower limit for their
clocks' rates. Up until now, support for that has been implemented
separately for each clock type.
Implement that functionality in the sunxi-ng's common part making use of
the CCF rate liming capabilities, so that it is
On some pinephones the video output sometimes freezes (flips between two
frames) [1]. It seems to be that the reason for this behaviour is that
PLL-MIPI is outside its limits, and the GPU is not running at a fixed
rate.
In this patch series I propose the following changes:
1. sunxi-ng: Adhere
On Mon, 04 Mar 2024 11:06:39 +0530, Dharma Balasubiramani wrote:
> Convert the atmel,lcdc bindings to DT schema.
> Changes during conversion: add missing clocks and clock-names properties.
>
> Signed-off-by: Dharma Balasubiramani
> ---
> This patch converts the existing lcdc display text
Convert the atmel,lcdc bindings to DT schema.
Changes during conversion: add missing clocks and clock-names properties.
Signed-off-by: Dharma Balasubiramani
---
This patch converts the existing lcdc display text binding to JSON schema.
The binding is split into two namely
lcdc.yaml
- Holds the
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+
Hi Rob
This is resend v2 of replace of_graph_get_next_endpoint()
We should get rid of or minimize of_graph_get_next_endpoint() in
its current form. In general, drivers should be asking for a specific
port number because their function is fixed in the binding.
On 01/03/24 11:40 pm, Rob Herring wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Thu, Feb 29, 2024 at 06:25:56AM +, dharm...@microchip.com wrote:
>> On 28/02/24 3:53 pm, Krzysztof Kozlowski wrote:
>>> EXTERNAL EMAIL: Do not click
From: kuro chung
ITE added a FIFO reset bit for input video. When system power resume,
the TTL input of it6505 may get some noise before video signal stable
and the hardware function reset is required.
But the input FIFO reset will also trigger error interrupts of output module
rising.
Thus,
From: kuro chung
New patch description for v2 patch
Missing declaration for i variable in function
it6505_irq_video_error_handler
, add it by this patch
Origianl description for v1 patch
drm/bridge: it6505: fix hibernate to resume no display issue
ITE added
On Sun, Mar 3, 2024 at 4:46 AM Duoming Zhou wrote:
>
> The kcalloc() in nouveau_dmem_evict_chunk() will return null if
> the physical memory has run out. As a result, if we dereference
> src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs
> will happen.
>
> This patch uses stack
Hi all,
FIXME: Add owner of second tree to To:
Add author(s)/SOB of conflicting commits.
Today's linux-next merge of the drm tree got conflicts in:
drivers/gpu/drm/xe/xe_exec_queue.c
drivers/gpu/drm/xe/xe_exec_queue_types.h
between commit:
eaa367a0317e ("drm/xe/uapi: Remove
Hi all,
Today's linux-next merge of the drm tree got conflicts in:
drivers/gpu/drm/xe/xe_bo.c
drivers/gpu/drm/xe/xe_bo.h
between commits:
a09946a9a903 ("drm/xe/xe_bo_move: Enhance xe_bo_move trace")
8188cae3cc3d ("drm/xe/xe_trace: Add move_lacks_source detail to xe_bo_move
trace")
On Thu, 29 Feb 2024 at 19:11, Doug Anderson wrote:
>
> Hi,
>
> On Thu, Feb 29, 2024 at 8:43 AM Jani Nikula
> wrote:
> >
> > On Wed, 28 Feb 2024, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Tue, Feb 27, 2024 at 5:27 PM Hsin-Yi Wang wrote:
> > >>
> > >> On Tue, Feb 27, 2024 at 1:09 AM Jani
On Thu, 29 Feb 2024 at 11:27, Luca Weiss wrote:
>
> On Wed Jan 17, 2024 at 9:59 AM CET, Luca Weiss wrote:
> > On Mon Jan 15, 2024 at 9:43 AM CET, Neil Armstrong wrote:
> > > Hi Luca,
> > >
> > > On 11/01/2024 13:38, Luca Weiss wrote:
> > > > Since the kconfig symbol of DRM_PANEL_BRIDGE is only
On Fri, 1 Mar 2024 at 19:52, Rob Herring wrote:
>
> On Tue, Feb 27, 2024 at 04:45:25PM +0100, Krzysztof Kozlowski wrote:
> > On 22/02/2024 16:55, Abel Vesa wrote:
> > > Add the X1E80100 to the list of compatibles and document the is-edp
> > > flag. The controllers are expected to operate in DP
Hi,
On 3/1/24 12:29, Philipp Stanner wrote:
> When the PCI devres API was introduced to this driver, it was wrongly
> assumed that initializing the device with pcim_enable_device() instead
> of pci_enable_device() will make all PCI functions managed.
>
> This is wrong and was caused by the quite
On Fri, 23 Feb 2024 13:13:58 +0100
Nuno Sa wrote:
> Hi Jonathan, likely you're wondering why I'm sending v7. Well, to be
> honest, we're hoping to get this merged this for the 6.9 merge window.
> Main reason is because the USB part is already in (so it would be nice
> to get the whole thing in).
Hi Anatoliy,
kernel test robot noticed the following build warnings:
[auto build test WARNING on bfa4437fd3938ae2e186e7664b2db65bb8775670]
url:
https://github.com/intel-lab-lkp/linux/commits/Anatoliy-Klymenko/drm-xlnx-zynqmp_dpsub-Set-layer-mode-during-creation/20240227-124631
base:
On Sun, Mar 03, 2024 at 09:44:03AM -0600, Adam Ford wrote:
> On Wed, Feb 28, 2024 at 10:31 AM Laurent Pinchart wrote:
> > On Wed, Feb 28, 2024 at 05:37:35AM -0600, Adam Ford wrote:
> > > The IRQ registration currently assumes that the GPIO is
> > > dedicated to it, but that may not necessarily be
On Wed, Feb 28, 2024 at 10:31 AM Laurent Pinchart
wrote:
>
> Hi Adam,
>
> Thank you for the patch.
>
> On Wed, Feb 28, 2024 at 05:37:35AM -0600, Adam Ford wrote:
> > The IRQ registration currently assumes that the GPIO is
> > dedicated to it, but that may not necessarily be the case.
> > If the
On Fri, Mar 1, 2024 at 2:23 AM Sid Pranjale
wrote:
>
> Nouveau deallocates a few buffers post GPU init which are required for GPU
> suspend/resume to function correctly.
> This is likely not as big an issue on systems where the NVGPU is the only
> GPU, but on multi-GPU set ups it leads to a
Reviewed-by: Simon Ser
[adding a bunch of list and people as well as Timur Tabi, who authored
the culprit]
Sid Pranjale, thx for the report. FWIW, I'm just replying to add this to
the regression tracking to ensure it does not fall through the cracks.
Nevertheless let me mention two things while at it:
On 29.02.24
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 216c1282dde38ca87ebdf1ccacee5a0682901574
commit: d72f049087d4f973f6332b599c92177e718107de [12/14] drm/panthor: Allow
driver compilation
config: s390-allyesconfig
(https://download.01.org/0day-ci/archive/20240303
The kcalloc() in nouveau_dmem_evict_chunk() will return null if
the physical memory has run out. As a result, if we dereference
src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs
will happen.
This patch uses stack variables to replace the kcalloc().
Fixes: 249881232e14
Hi Jacopo,
Thank you for this patch.
On Mon, 26 Feb 2024 at 13:26, Jacopo Mondi
wrote:
>
> Add FourCC definitions for the 48-bit RGB/BGR formats to the
> DRM/KMS uapi.
>
> The format will be used by the Raspberry Pi PiSP Back End,
> supported by a V4L2 driver in kernel space and by libcamera in
On 2/29/24 15:30, Ville Syrjälä wrote:
I prefer the current way where we have no side effects in
the if statement.
This seem like a valid concern from readability and maintainability
standpoint. My patch was aimed mostly at performance and maintainability
using tools: some more pedantic
On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov wrote:
>
> I agree, it's hard to imagine even a simple majority agreeing on how GitLab CI
> should be done. Still, we would like to help people, who are interested in
> this kind of thing, to set it up. How about we reframe this contribution as a
>
Thanks for stopping by, Linus!
On 2/29/24 10:21 PM, Linus Torvalds wrote:
> On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov wrote:
>>
>> However, I think a better approach would be *not* to add the .gitlab-ci.yaml
>> file in the root of the source tree, but instead change the very same repo
>>
On 29/02/2024 17:28, Nicolas Dufresne wrote:
> Hi,
>
> Le jeudi 29 février 2024 à 16:16 +0200, Nikolai Kondrashov a écrit :
>> On 2/29/24 2:20 PM, Guillaume Tucker wrote:
>>> Hello,
>>>
>>> On 28/02/2024 23:55, Helen Koike wrote:
Dear Kernel Community,
This patch introduces a
On 3/1/24 4:07 PM, Mark Brown wrote:
On Fri, Mar 01, 2024 at 12:27:13PM +0200, Nikolai Kondrashov wrote:
On 2/29/24 10:21 PM, Linus Torvalds wrote:
I would suggest the CI project be separate from the kernel.
It is possible to have a GitLab CI setup with the YAML files in a separate
Add Device Tree bindings for Texas Instruments LM3509 - a
High Efficiency Boost for White LED's and/or OLED Displays
Signed-off-by: Patrick Gansterer
---
.../bindings/leds/backlight/ti,lm3509.yaml| 81 +++
1 file changed, 81 insertions(+)
create mode 100644
This is a general driver for LM3509 backlight chip of TI.
LM3509 is High Efficiency Boost for White LEDs and/or OLED Displays with
Dual Current Sinks. This driver supports OLED/White LED select, brightness
control and sub/main control.
The datasheet can be found at
On Sun, Mar 3, 2024 at 3:30 AM Randy Dunlap wrote:
> On 3/2/24 14:10, Guenter Roeck wrote:
> > On Thu, Feb 29, 2024 at 12:21 PM Linus Torvalds
> > wrote:
> >> On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov wrote:
> >>>
> >>> However, I think a better approach would be *not* to add the
> >>>
43 matches
Mail list logo
