Hi Laurent,
> > Read out and check the ID registers, so we can bail out if I2C
> > communication does not work or if the device is unknown.
>
> What's the advantage of that, what are you trying to guard against ?
That a random chip at address 0x2c will be used.
> > Tested on a
> > Renesas GrayH
On Tue, Mar 18, 2025 at 04:52:56PM +0100, Wolfram Sang wrote:
> Read out and check the ID registers, so we can bail out if I2C
> communication does not work or if the device is unknown. Tested on a
> Renesas GrayHawk board (R-Car V4M) by using a wrong I2C address and by
> not enabli
Read out and check the ID registers, so we can bail out if I2C
communication does not work or if the device is unknown. Tested on a
Renesas GrayHawk board (R-Car V4M) by using a wrong I2C address and by
not enabling RuntimePM for the device.
Signed-off-by: Wolfram Sang
---
Changes since v2
> where leaving the dangling devices isn't really a problem. For
> instance: if somehow you fail to link up to a MIPI source then it
> feels OK that the GPIO / PWM and DP-AUX bus parts of the bridge
> continue to dangle. You can still use them, right?
Ok, convinced. Thanks for the input. Will sen
> > Just to make sure: there can only be one bridge, right? Because the
> > suggested name is not unique.
>
> Bridges can be chained. It's highly unlikely that a chain would contain
> multiple bridges of the same model, as that would be quite pointless,
> but in theory it could happen.
Thanks fo
> We don't have a practice yet. Keeping dev_name() was Doug's suggestion.
> But I like your idea better, so I will change to it. Thank you for it!
Just to make sure: there can only be one bridge, right? Because the
suggested name is not unique.
signature.asc
Description: PGP signature
> > + struct dentry *debugfs = debugfs_create_dir(dev_name(it6505->dev),
> > root);
I will switch away from dev_name() here, too, of course.
> > int i = 0;
> >
> > while (debugfs_entry[i].name && debugfs_entry[i].fops) {
> > debugfs_create_file(debugfs_entry[i].name, 064
On Sun, Mar 16, 2025 at 12:43:48AM +0200, Dmitry Baryshkov wrote:
> On Sat, Mar 15, 2025 at 09:15:11PM +0100, Wolfram Sang wrote:
> > Do not create a custom directory in debugfs-root, but use the
> > debugfs_init callback to create a custom directory at the given place
> > fo
Do not create a custom directory in debugfs-root, but use the
debugfs_init callback to create a custom directory at the given place
for the bridge.
Signed-off-by: Wolfram Sang
---
Only build tested, but following the same pattern as the tested
ti-sn65dsi86.
Changes since v1:
* switch from
-002c
Signed-off-by: Wolfram Sang
---
Changes since v1:
* switch from 'client->debugfs' to DRM 'debugfs_init' callback
* remove RFT because tested on hardware
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 40 +++
1 file changed, 10 insertions(+), 30 del
Hi Doug,
> Seems reasonable to me. I would probably put an error message in this
> case, though? I don't think regmap_read() necessarily prints an error
> so it would just be a mysterious failure for why things didn't probe,
> right?
OK, can do that.
> This also only solves the problems for one
From: Phong Hoang
Add a check to the very first register access function when attaching a
bridge device, so we can bail out if I2C communication does not work.
Signed-off-by: Phong Hoang
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
Signed-off-by: Wolfram Sang
---
Build tested
> I gave it a try on Gray Hawk Single.
Oh, we have such a board? Nice! That would help a lot.
signature.asc
Description: PGP signature
Hi Doug!
> wanted it in panel-edp, but glad it's useful for other cases. ;-)
:)
> want some type of directory under there. In ti-sn65dsi86's case you
> could presumably keep the existing behavior where it creates a
> directory under there called "1-002c".
The good news is that I learnt now that
Hi Dmitry,
thanks for the review!
> > The I2C core now offers a debugfs-directory per client. Use it and
> > remove the custom handling in drm bridge drivers. I don't have the
> > hardware, so I hope I can find people willing to test here. Build bots
> > are happy. And for it6505, it even fixes a
oking forward to comments.
Wolfram Sang (2):
drm/bridge: it6505: Use per-client debugfs entry
drm/bridge: ti-sn65dsi86: Use per-client debugfs entry
drivers/gpu/drm/bridge/ite-it6505.c | 28 +++---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 29 +
The I2C core now offers a debugfs-directory per client. Use it and
remove the custom handling. This also fixes the problem of a static
debugfs dir name which would break if two of these devices would be on
one system.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/bridge/ite-it6505.c | 28
The I2C core now offers a debugfs-directory per client. Use it and
remove the custom handling.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 29 +--
1 file changed, 1 insertion(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti
Hi Konrad,
> Already sent a series of fixups, but thanks for keeping track
Welcome. Cool that you are at it!
Happy hacking,
Wolfram
signature.asc
Description: PGP signature
The old email address bounced. I found the newer one in MAINTAINERS,
so update entries accordingly.
Cc: Konrad Dybcio
Signed-off-by: Wolfram Sang
---
Against v6.11-rc1. Still needs ack from Konrad Dybcio
MAINTAINERS | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a
vchenko
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
> > remove I2C_CLASS_SPD without further dependencies? If you prefer to push
> > it through your tree, can you send it to Linus soon?
>
> Yes, I'll include the patch in my PR for this week.
Awesome, thank you!
signature.asc
Description: PGP signature
Hi Alex,
On Thu, May 09, 2024 at 01:15:32PM -0400, Alex Deucher wrote:
> On Thu, May 9, 2024 at 8:02 AM Heiner Kallweit wrote:
> >
> > Support for I2C_CLASS_SPD is currently being removed from the kernel.
> > Only remaining step is to remove the definition of I2C_CLASS_SPD.
> > Setting I2C_CLASS
On Thu, Apr 18, 2024 at 10:55:39PM +0200, Heiner Kallweit wrote:
> 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
> instantiation") removed the last call to i2c_mux_add_adapter() with a
> non-null class argument. Therefore the class argument can be removed.
>
> Note: Class-ba
> I will change the subject line to s/comeda/komeda/ when merging it.
Oh, thank you!
signature.asc
Description: PGP signature
the return value directly to drop
'timeout' which also fixes its wrong type.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers
On Thu, Apr 18, 2024 at 10:55:39PM +0200, Heiner Kallweit wrote:
> 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
> instantiation") removed the last call to i2c_mux_add_adapter() with a
> non-null class argument. Therefore the class argument can be removed.
>
> Note: Class-ba
> > /* wait the flip take affect.*/
> > - timeout = wait_for_completion_timeout(flip_done, HZ);
> > - if (timeout == 0) {
> > + time_left = wait_for_completion_timeout(flip_done, HZ);
> > + if (time_left == 0) {
>
> Honestly, if the name of the variable is confusing I would get rid of
7;time_left' as a variable to make the code
self explaining.
Fix to the proper variable type 'unsigned long' while here.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/driv
Hi Easwar,
> Sorry, got excited. :) There were drivers I'd been part of that I specifically
> wanted to fixup, but then the scope grew to other users of algobit.
Well, you got some positive feedback, so that is good.
> > It is true that I changed quite some controller drivers within the i2c
> >
Hello Easwar,
On Fri, Mar 29, 2024 at 05:00:24PM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of the
>
l former
> users on these platforms have been converted to the SH-Mobile DRM
> driver, using DT.
>
> Suggested-by: Arnd Bergmann
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
signature.asc
Description: PGP signature
On Mon, Nov 13, 2023 at 12:37:15PM +0100, Heiner Kallweit wrote:
> I2C_CLASS_SPD was used to expose the EEPROM content to user space,
> via the legacy eeprom driver. Now that this driver has been removed,
> we can remove I2C_CLASS_SPD support. at24 driver with explicit
> instantiation should be use
> I created an immutable branch for this which the buildbots will
> hopefully check over night. I will reply with comments tomorrow when I
> got the buildbot results.
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Thu, Nov 23, 2023 at 10:40:20AM +0100, Heiner Kallweit wrote:
> After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
> olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
> Class-based device auto-detection is a legacy mechanism and shouldn't
> be used in new
> We're not in a hurry. It's just my experience with patch series' affecting
> multiple subsystems that typically the decision was to apply the full
> series via one tree. Also to avoid inquires from maintainers like:
> Shall I take it or are you going to take it?
> Of course there may be differen
> Preferably this series should be applied via the i2c tree.
Are we in a hurry here, i.e. does it block further development of the
i801 smbus driver? My gut feeling says the patches should rather go via
drm and fbdev trees, but I may be convinced otherwise.
signature.asc
Description: PGP signa
Kozlowski
>
> ---
>
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
I am fine that you take it once all review comments are addressed. Given
that:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
Kozlowski
>
> ---
>
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
I am fine that you take it once all review comments are addressed. Given
that:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
Not RCAR, but R-Car.
Signed-off-by: Wolfram Sang
Reviewed-by: Kieran Bingham
Reviewed-by: Geert Uytterhoeven
---
Changes since v2:
* rebased to 6.6
* added Geert's tag (thanks!)
drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Hi Guenter,
> I didn't (want to) say that. I am perfectly happy with driver specific
> code, and I would personally still very much prefer it. I only wanted to
> suggest that _if_ a generic solution is implemented, it should cover all
> existing use cases and not just this one. But, really, I'd ra
Hi Guenter,
> > > Reference to Andrew's previous proposal:
> > > https://lore.kernel.org/all/20200914122811.3295678-1-and...@aj.id.au/
> >
> > I do totally agree with Guenter's comment[1], though. This just affects
> > a few drivers and this patch is way too intrusive for the I2C core. The
> > la
Hi,
thanks for this series!
> Reference to Andrew's previous proposal:
> https://lore.kernel.org/all/20200914122811.3295678-1-and...@aj.id.au/
I do totally agree with Guenter's comment[1], though. This just affects
a few drivers and this patch is way too intrusive for the I2C core. The
later sug
Since commit ab78029ecc34 ("drivers/pinctrl: grab default handles from
device core"), we can rely on device core for setting the default pins.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/
Not RCAR, but R-Car.
Signed-off-by: Wolfram Sang
Reviewed-by: Kieran Bingham
---
Changes since v1:
* rebased to 6.6-rc2
* added tag from Kieran (Thanks!)
drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
Not RCAR, but R-Car.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h
b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h
index f9893d7d6dfc
> > Without of_node, devm_clk_get() and friends falls back to registered
> > clkdevs. So you could call clk_register_clkdev() from within the
> > PMIC driver, and can keep on using devm_clk_get_optional() in the
> > ISL1208 driver.
>
> Seriously, how many hacks are we piling ? :-)
For this parti
Hi everyone,
> Perhaps we should first think through what an ancillary device really
> is. My understanding is that it is used to talk to secondary addresses
> of a multi-address I2C slave device.
As I mentioned somewhere before, this is not the case. Ancillary devices
are when one *driver* hand
Hi Geert,
> > Would this binding allow to not use the RTC if the second reg is
> > missing? What are the advantages of not enabling RTC? Saving power?
>
> It doesn't work if there is no clock?
Maybe I am confusing something now, but if the RTC _needs_ to be
enabled, then why we don't do it uncon
Hi Biju,
> DT-Maintainers suggestion:
> [1]
> raa215300: pmic@12 {
> compatible = "renesas,raa215300";
> reg = <0x12>, <0x6f>;
> reg-names = "main", "rtc";
>
> clocks = <&x2>;
> clock-names = "xin";
> /* Add Optional shared IRQ resource and share it to child an
Hi all,
sorry for not being able to chime in earlier.
> In Biju's particular use case, the i2c device responds to two addresses,
> which is the standard i2c ancillary use case. However, what's special
Not quite. ancillary is used when a *driver* needs to take care of two
addresses. We already h
> Wolfram: time to chime in ;-)
I'll have a look this week.
signature.asc
Description: PGP signature
: Wolfram Sang
Reviewed-by: Kieran Bingham
---
This is the last ES1 bit remaining, would be awesome if it could go
soon.
Changes since v1:
* rebased to 6.4-rc1 (no code updates needed)
* added Kieran's tag (thanks!)
* mention in commit message that ES1 doesn't even boot anymore
drive
cking!
Wolfram Sang (11):
iommu/ipmmu-vmsa: remove R-Car H3 ES1.* handling
drm: rcar-du: remove R-Car H3 ES1.* workarounds
media: rcar-vin: remove R-Car H3 ES1.* handling
media: rcar-vin: csi2: remove R-Car H3 ES1.* handling
media: renesas: fdp1: remove R-Car H3 ES1.* handling
th
: Wolfram Sang
---
Please apply individually per subsystem. There are no dependencies and the SoC
doesn't boot anymore since v6.3-rc1.
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 37 ++--
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 48 --
drivers/gpu/drm/rc
{/'
>
> With this, a few errors in examples were exposed and fixed.
>
> Signed-off-by: Rob Herring
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
> Yes, that's the plan. We're collecting the various patches people have sent
> in for arch/sh, review and test them and apply them.
>
> My test board is running the latest kernel now, so I can test new patches,
> too.
I am just witnessing this development, but I want to say thanks for your
eff
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wo
> As some conflicts are expected I sent this early after -rc1 such that it
> can be included early into next and be put on an immutable branch for
> subsystems to resolve merge conflicts.
I pushed the series out now, so it should hit -next tomorrow.
The immutable branch is here:
git://git.kerne
On Mon, Aug 15, 2022 at 10:02:25AM +0200, Uwe Kleine-König wrote:
> A remove callback that just returns 0 is equivalent to no callback at all
> as can be seen in i2c_device_remove(). So simplify accordingly.
>
> Signed-off-by: Uwe Kleine-König
Applied to an immutable branch, thanks!
signature
On Sun, Aug 07, 2022 at 11:04:54PM +0900, Robin Reckmann wrote:
> Fix i2c transfers using GPI DMA mode for all message types that do not set
> the I2C_M_DMA_SAFE flag (e.g. SMBus "read byte").
>
> In this case a bounce buffer is returned by i2c_get_dma_safe_msg_buf(),
> and it has to synced back t
On Sun, Aug 07, 2022 at 11:04:54PM +0900, Robin Reckmann wrote:
> Fix i2c transfers using GPI DMA mode for all message types that do not set
> the I2C_M_DMA_SAFE flag (e.g. SMBus "read byte").
>
> In this case a bounce buffer is returned by i2c_get_dma_safe_msg_buf(),
> and it has to synced back t
> I'm getting quite a bunch of unrelated mails because the regex is not the
> best.
I can imagine!
> On the other hand the framework is used in a lot of drivers and I do want to
> be notified when they mess with their interfaces.
Sure thing. I am convinced the regex can be improved to ensure th
Hi Christian,
> Maybe call your variable differently. DMA-buf is an inter driver buffer
> sharing frame we use for GPU acceleration and V4L.
>
> It doesn't cause any technical issues, but the maintainer regex now triggers
> on that. So you are CCing people not related to this code in any way.
Fr
On Thu, Nov 25, 2021 at 10:23:44PM +0530, Akhil R wrote:
> Add support for the ACPI based device registration so that the driver
> can be also enabled through ACPI table.
>
> This does not include the ACPI support for Tegra VI and DVC I2C.
>
> Signed-off-by: Akhil R
Applied to for-next, thanks!
ed.
>
> Signed-off-by: Michael S. Tsirkin
Acked-by: Wolfram Sang # for I2C changes
signature.asc
Description: PGP signature
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
drivers/gpu/drm/panfrost/panfrost_device.c | 6 ++
1 file changed, 2 insert
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
drivers/gpu/drm/msm/
ptr =
- platform_get_drvdata(pdev)
+ dev_get_drvdata(d)
<... when != pdev
- &pdev->dev
+ d
...>
Kind regards,
Wolfram
Wolfram Sang (9):
dmaengine: stm32-dmamux: simplify getting .driver_data
firmware: meson: simplify getting .driver_data
gpio
On Wed, Apr 28, 2021 at 05:57:55PM +0530, Shubhankar Kuranagatti wrote:
> Multi line comment have been aligned starting with a *
> The closing */ has been shifted to a new line.
> Single space replaced with tab space
> This is done to maintain code uniformity.
A step in the right direction but sti
Palmer Dabbelt
> Cc: Albert Ou
> Cc: Alessandro Zummo
> Cc: Alexandre Belloni
> Cc: Greg Kroah-Hartman
> Cc: Mark Brown
> Cc: Zhang Rui
> Cc: Daniel Lezcano
> Cc: Wim Van Sebroeck
> Cc: Guenter Roeck
> Signed-off-by: Rob Herring
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
> Hi, this issue is fixed in
> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-gt-next&id=5b11705608898c31a1cae5340555ee60d5a4fa45
>
> And I think the pull request is in
> https://lists.freedesktop.org/archives/intel-gfx/2021-May/267588.html
Thanks for the heads up. So, I'll wait with
[PATCH] drm/i915/selftests: Avoid name clash with pm_ global
> functions
>
> Signed-off-by: Stephen Rothwell
Looks like the proper solution to me. I think this should be added to
the i915 tree. D'accord everyone?
Reviewed-by: Wolfram Sang
Kind regards,
Wolfram
signature.asc
Description: PGP signature
rokhov
> Acked-by: Krzysztof Kozlowski # for drivers/memory
> Acked-by: Mark Brown
> Acked-by: Dmitry Torokhov
> Acked-by: Linus Walleij
> Signed-off-by: Uwe Kleine-König
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
___
On Tue, Nov 24, 2020 at 12:57:43PM -0600, Bjorn Andersson wrote:
> A combination of recent bug fixes by Doug Anderson and the proper
> definition of iommu streams means that this hack is no longer needed.
> Let's clean up the code by reverting '127068abe85b ("i2c: qcom-geni:
> Disable DMA processin
alsa-de...@alsa-project.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-...@lists.infradead.org
> Cc: linux-ser...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rob Herring
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
__
dProperties' or 'additionalProperties'. This has been a
> constant source of review issues.
>
> Signed-off-by: Rob Herring
I trust you, so for I2C:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index e32ef3f01fe8..b13b1cbcac29 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -1785,7 +1785,7 @@ static int i801_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
>
..@alsa-project.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-...@lists.infradead.org
> Cc: net...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-ser...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rob Herring
I trust you guys in figuring out the details, so fo
On Tue, Jul 07, 2020 at 11:04:03AM -0700, Randy Dunlap wrote:
> Drop doubled word "new".
>
> Signed-off-by: Randy Dunlap
For the record:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
___
dri-devel mai
On Tue, Jul 07, 2020 at 11:04:03AM -0700, Randy Dunlap wrote:
> Drop doubled word "new".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Wolfram Sang
> Cc: linux-...@vger.kernel.org
Reviewed-by: Wolfram Sang
Hi Alexander,
thanks for trying to fix this, yet I have some doubts.
On Mon, Jun 29, 2020 at 10:31:21PM +0200, Alexander A. Klimov wrote:
> Rationale:
> https://lore.kernel.org/linux-doc/20200626110706.7b5d4...@lwn.net/
I think we need some text here. Clicking on a link to understand what a
patc
On Mon, Jun 15, 2020 at 09:58:09AM +0200, Wolfram Sang wrote:
> I want to remove the above API this cycle, and just a few patches have
> not made it into 5.8-rc1. They have been reviewed and most had been
> promised to get into linux-next, but well, things happen. So, I hope it
>
module_put() balances try_module_get(), not request_module(). Fix the
error path to match that.
Fixes: 2066facca4c7 ("drm/kms: slave encoder interface.")
Signed-off-by: Wolfram Sang
Reviewed-by: Emil Velikov
---
I'd like to push it via I2C for 5.8-rc2.
drivers/gpu/drm/drm_enco
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
Reviewed-by: Daniel Thompson
---
I'd like to push it via I2C for 5.8-rc2.
drivers/video/backlight/tosa_lcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --
minor exception is the media documentation patch which I simply have
missed so far, but it is trivial.
And then, finally, there is the removal of the old API as the final
patch. Phew, that's been a long ride.
I am open for comments, of course.
Happy hacking,
Wolfram
Wolfram Sang (6):
we use this condensed error check.
Signed-off-by: Wolfram Sang
Reviewed-by: Emil Velikov
---
I'd like to push it via I2C for 5.8-rc2.
drivers/gpu/drm/drm_encoder_slave.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave
vblank init message is displayed again when the DU driver
is retried. Because the message doesn't really carry a useful
information, I suggest to simply drop it.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/drm_vblank.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gp
On Mon, Mar 16, 2020 at 05:39:05PM +0100, Wolfram Sang wrote:
> While converting I2C users to new APIs, I found a refcounting problem in
> the encoder_slave implementation. This series fixes it and converts to
> the new API.
>
> Based on linux-next and only build tested.
>
On Fri, Apr 17, 2020 at 11:14:46AM +0100, Lee Jones wrote:
> On Thu, 26 Mar 2020, Wolfram Sang wrote:
>
> > Move away from the deprecated API and return the shiny new ERRPTR where
> > useful.
> >
> > Signed-off-by: Wolfram Sang
> > ---
> > drivers/
On Fri, Apr 24, 2020 at 05:33:42PM +0200, Maxime Ripard wrote:
> The BCM2711, supported by ARCH_BCM2835, also has a controller by the
> brcmstb driver so let's allow it to be compiled on that platform.
>
> Cc: Kamal Dasu
> Cc: Wolfram Sang
> Cc: bcm-kernel-feedback-l...@b
On Fri, Apr 24, 2020 at 10:07:25AM -0700, Florian Fainelli wrote:
>
>
> On 4/24/2020 9:13 AM, Wolfram Sang wrote:
> >
> >> config I2C_BRCMSTB
> >>tristate "BRCM Settop/DSL I2C controller"
> >> - depends on ARCH_BRCMSTB || BMIPS_GENERIC |
> config I2C_BRCMSTB
> tristate "BRCM Settop/DSL I2C controller"
> - depends on ARCH_BRCMSTB || BMIPS_GENERIC || ARCH_BCM_63XX || \
> -COMPILE_TEST
> + depends on ARCH_BCM2835 || ARCH_BRCMSTB || BMIPS_GENERIC || \
> +ARCH_BCM_63XX || COMPILE_TEST
Isn
ments, so let's change this
> treewide so everyone copies the simpler syntax.
>
> Signed-off-by: Rob Herring
Same preamble for my ack as in patch 1:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
___
dri-devel mailing
scripts which do transforms on the schema files.
>
> Signed-off-by: Rob Herring
I see that people had comments but I can't judge the topics raised. So,
I trust you guys that you find out when it is good to go and for that,
here is my ack:
Acked-by: Wolfram Sang
signature.as
ments, so let's change this
> treewide so everyone copies the simpler syntax.
>
> Signed-off-by: Rob Herring
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
scripts which do transforms on the schema files.
>
> Signed-off-by: Rob Herring
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.o
> > > > Move away from the deprecated API.
> > > >
> > > > Signed-off-by: Wolfram Sang
> > >
> > > patches 1,6, are:
> > > Acked-by: Alex Deucher
> > Should we commit all to drm-misc-next?
>
> I'm fine to see it go
1 - 100 of 309 matches
Mail list logo
