Hi Pin-yen Lin,
1. What would happen if we remove the loop and only check the video error
interrupts once? If another video error interrupt comes out, we handle it in
the next interrupt handler. Will this lead to an infinite loop?
2. Why do we run the loop for 10 times (100ms as you mentioned)
/20240310/202403101225.7ahejhzj-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Reported-by: Dan Carpenter
| Closes
On Tue, Mar 05, 2024 at 10:40:28AM -0800, Guenter Roeck wrote:
> Some unit tests intentionally trigger warning backtraces by passing bad
> parameters to kernel API functions. Such unit tests typically check the
> return value from such calls, not the existence of the warning backtrace.
>
> Such in
On 3/8/24 4:47 PM, David Wei wrote:
>
> I'm working to port bnxt over to using this API. What are your thoughts
> on maybe pulling this out and use bnxt to drive it?
>
I would love to see a second nic implementation; this patch set and
overall design is driven by GVE limitations.
Hello Frank,
On Sun, Mar 10, 2024 at 02:32:29PM +0100, Frank Oltmanns wrote:
> +static int sun4i_rate_reset_notifier_cb(struct notifier_block *nb,
> + unsigned long event, void *data)
> +{
> + struct sun4i_rate_reset_nb *rate_reset = to_sun4i_rate_reset_nb(nb)
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: b219865715e419435ad49dc2300fe3f85c79d3f6
commit: d6eb77731c45caf6ee7b18d907e9bc44be760e8c [1/1] Merge drm/drm-next into
drm-misc-next
config: x86_64-allyesconfig
(https://download.01.org/0day-ci/archive/20240311/202403110614
From: Tobias Jakobi
Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/
This patch changes drm_mode_legacy_fb_format() to only return formats
which are supported by the current drm-device. The motivation for this
change is to fix a regression introduced by commit
c91acda3a380 ("drm/gem: Check for valid formats") which stops the Xorg
modesetting driver from working on t
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 http://www.ti.com/product/lm3509.
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
Reviewed-by: Krzysztof Kozlowski
---
Changes in v4:
Use backlight_*() to access backlight_device
Do not set backlight_properties.power
v3: ht
Allow the dclk to reset its rate when a rate change is initiated from an
ancestor clock. This makes it possible to no longer to get an exclusive
lock. As a consequence, it is now possible to set new rates if
necessary, e.g. when an external display is connected.
The first user of this functionalit
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 insertions(+),
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 whi
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
---
drivers/clk/sunxi-ng
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 availabl
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 to
Document the new DMABUF based API.
Signed-off-by: Paul Cercueil
Signed-off-by: Nuno Sa
---
v2: - Explicitly state that the new interface is optional and is
not implemented by all drivers.
- The IOCTLs can now only be called on the buffer FD returned by
IIO_BUFFER_GET_FD_IOCTL.
Use the functions provided by the buffer-dma core to implement the
DMABUF userspace API in the buffer-dmaengine IIO buffer implementation.
Since we want to be able to transfer an arbitrary number of bytes and
not necesarily the full DMABUF, the associated scatterlist is converted
to an array of DM
Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
DMA buffer implementations.
Signed-off-by: Paul Cercueil
Signed-off-by: Nuno Sa
---
v3: Update code to provide the functions that will be used as call
Add the necessary infrastructure to the IIO core to support a new
optional DMABUF based interface.
With this new interface, DMABUF objects (externally created) can be
attached to a IIO buffer, and subsequently used for data transfer.
A userspace application can then use this interface to share DM
Add implementation of the .device_prep_peripheral_dma_vec() callback.
Signed-off-by: Paul Cercueil
Signed-off-by: Nuno Sa
---
v3: New patch
v5: Implement .device_prep_slave_dma_vec() instead of v3's
.device_prep_slave_dma_array().
v6: Use new prototype for axi_dmac_alloc_desc() as it chan
This function can be used to initiate a scatter-gather DMA transfer,
where the address and size of each segment is located in one entry of
the dma_vec array.
The major difference with dmaengine_prep_slave_sg() is that it supports
specifying the lengths of each DMA transfer; as trying to override t
Hi Jonathan,
Here's the final-er version of the IIO DMABUF patchset.
This v9 fixes the few issues reported by the kernel bot.
This was based on next-20240308.
Changelog:
- [3/6]:
- Select DMA_SHARED_BUFFER in Kconfig
- Remove useless forward declaration of 'iio_dma_fence'
- Import
On Fri, 8 Mar 2024 18:00:40 +0100
Paul Cercueil wrote:
> Hi Jonathan,
>
> Here's the final(tm) version of the IIO DMABUF patchset.
>
> This v8 fixes the remaining few issues that Christian reported.
>
> I also updated the documentation patch as there has been changes to
> index.rst.
>
> This
.com/intel-lab-lkp/linux/commits/Sam-Ravnborg-via-B4-Relay/sparc32-Update-defconfig-to-LEON-SMP/20240310-021717
> base: 84b76d05828a1909e20d0f66553b876b801f98c8
> patch link:
> https://lore.kernel.org/r/20240309-sunset-v2-14-f09912574d2c%40ravnborg.org
> patch subject: [PATCH v2 14
kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
patch link:
https://lore.kernel.org/r/20240308170046.92899-4-paul%40crapouillou.net
patch subject: [PATCH v8 3/6] iio: core: Add new DMABUF interface infrastructure
config: um-randconfig-002-20240310
(https://download.01.org/0day-ci/archiv
Hi Sam,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 84b76d05828a1909e20d0f66553b876b801f98c8]
url:
https://github.com/intel-lab-lkp/linux/commits/Sam-Ravnborg-via-B4-Relay/sparc32-Update-defconfig-to-LEON-SMP/20240310-021717
base
Hi Patrick,
a few comments in the following.
Sam
On Sat, Mar 09, 2024 at 02:24:56PM +0100, Patrick Gansterer wrote:
> 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 sup
On 09/03/2024 14:24, Patrick Gansterer wrote:
> 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
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 09/03/2024 14:24, Patrick Gansterer wrote:
> 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
> ---
> Changes in v3:
> Improved device tree bindings documentation style
That's way too
31 matches
Mail list logo