Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers
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 > > realm. I did this to gain experience. As you also noticed quite some > > questions came up. We need to agree on answers first. And once we are > > happy with the answers we found, then IMO we can go outside of the i2c > > realm and send patches to other subsystems referencing agreed > > precedence. I intentionally did not go outside i2c yet. Since your > > patches are already there, you probably want to foster them until they > > are ready for inclusion. > > Sorry, I don't quite follow what you mean by foster in this context. Are > you asking me to hold off on merging the series, or to follow through on > getting it merged? I think they are your patches, so this is up to you to decide. With "foster", I meant you keep working on them until everyone is happy. I haven't looked at the drivers you modify. I can't tell if they can be converted right away or if they use a lot of I2C API calls, so that it makes sense to wait until the core is converted. I trust you to decide this. Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers
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 > I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists > in the specification. I really appreciate that you want to assist in this task to improve the I2C core. I do. I am afraid, however, that you took the second step before the first one, though. As I mentioned in my original cover letter, this is not only about renaming but also improving the I2C API (splitting up header files...). So, drivers are not a priority right now. They can be better fixed once the core is ready. It is true that I changed quite some controller drivers within the i2c realm. I did this to gain experience. As you also noticed quite some questions came up. We need to agree on answers first. And once we are happy with the answers we found, then IMO we can go outside of the i2c realm and send patches to other subsystems referencing agreed precedence. I intentionally did not go outside i2c yet. Since your patches are already there, you probably want to foster them until they are ready for inclusion. Yet, regarding further patches, my suggestion is to wait until the core is ready. That might take a while, though. However, there is enough to discuss until the core is ready. So, your collaboration there is highly appreciated! > The last patch updating the .master_xfer method to .xfer depends on > patch 1 of Wolfram's series below, but the series is otherwise > independent. It may make sense for the last patch to go in with Please drop the last patch from this series. It will nicely remove the dependency. Also, like above, I first want to gain experience with i2c before going to other subsystems. That was intended. All the best and happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH] fbdev: Restrict FB_SH_MOBILE_LCDC to SuperH
On Wed, Jan 31, 2024 at 05:08:23PM +0100, Geert Uytterhoeven wrote:
> Since commit f402f7a02af6956d ("staging: board: Remove Armadillo-800-EVA
> board staging code"), there are no more users of the legacy SuperH
> Mobile LCDC framebuffer driver on Renesas ARM platforms. All 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
Re: [PATCH] drm/amd/pm: Remove I2C_CLASS_SPD support
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 used instead. > > If in doubt this patch could be applied via the i2c tree. > > Signed-off-by: Heiner Kallweit Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH v5 00/20] remove I2C_CLASS_DDC support
> 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
Re: [PATCH v5 00/20] remove I2C_CLASS_DDC support
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 code. So we can remove this class completely now. > > Preferably this series should be applied via the i2c tree. > > v2: > - change tag in commit subject of patch 03 > - add ack tags > v3: > - fix a compile error in patch 5 > v4: > - more ack and review tags > v5: > - more acks > > Signed-off-by: Heiner Kallweit 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. signature.asc Description: PGP signature
Re: [PATCH 00/20] remove I2C_CLASS_DDC support
> 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 different opinions. Please advise. Ok, then this turns out to be a negotation thing between the drm/fbdev maintainers and me. I *can* take all the patches, of course. But since the number of patches touching the non-i2c subsystems is high, I'd like to hear their preference, too. signature.asc Description: PGP signature
Re: [PATCH 00/20] remove I2C_CLASS_DDC support
> 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 signature
Re: [PATCH 03/17] dt-bindings: i2c: samsung,s3c2410-i2c: add specific compatibles for existing SoC
On Wed, Nov 08, 2023 at 11:43:29AM +0100, Krzysztof Kozlowski wrote: > Samsung Exynos SoC reuses several devices from older designs, thus > historically we kept the old (block's) compatible only. This works fine > and there is no bug here, however guidelines expressed in > Documentation/devicetree/bindings/writing-bindings.rst state that: > 1. Compatibles should be specific. > 2. We should add new compatibles in case of bugs or features. > > Add compatibles specific to each SoC in front of all old-SoC-like > compatibles. > > Signed-off-by: Krzysztof 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
Re: [PATCH 02/17] dt-bindings: i2c: exynos5: add specific compatibles for existing SoC
On Wed, Nov 08, 2023 at 11:43:28AM +0100, Krzysztof Kozlowski wrote: > Samsung Exynos SoC reuses several devices from older designs, thus > historically we kept the old (block's) compatible only. This works fine > and there is no bug here, however guidelines expressed in > Documentation/devicetree/bindings/writing-bindings.rst state that: > 1. Compatibles should be specific. > 2. We should add new compatibles in case of bugs or features. > > Add compatibles specific to each SoC in front of all old-SoC-like > compatibles. > > Signed-off-by: Krzysztof 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
[PATCH v3] drm: renesas: rcar-du: use proper naming for R-Car
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 --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..e9e59c5e70d5 100644 --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h @@ -16,7 +16,7 @@ struct rcar_du_format_info; struct rcar_du_group; /* - * The RCAR DU has 8 hardware planes, shared between primary and overlay planes. + * The R-Car DU has 8 hardware planes, shared between primary and overlay planes. * As using overlay planes requires at least one of the CRTCs being enabled, no * more than 7 overlay planes can be available. We thus create 1 primary plane * per CRTC and 7 overlay planes, for a total of up to 9 KMS planes. -- 2.35.1
Re: [PATCH v1 0/2] [PATCH] hwmon: (pmbus/max31785) Add minimum delay between bus accesses
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 rather leave > that alone and not risk introducing regressions to existing drivers. Okay, seems we are aligned again :) > I don't know about this device, but in general the problem is that the > devices need some delay between some or all transfers or otherwise react > badly in one way or another. The problem is not always the same. Ok, that again doesn't speak for a generic solution IMO. > Lower bus frequencies don't help, at least not for the devices where > I have seen to problem myself. The issue is not bus speed, but time between > transfers. Typically the underlying problem is that there is some > microcontroller on the affected chips, and the microcode is less than > perfect. For example, the microcode may not poll its I2C interface > while it is busy writing into the chip's internal EEPROM or while it is > updating some internal parameters as result of a previous I2C transfer. I see. Well, as you probably know, EEPROMs not reacting because they are busy with an erase cycle is well-known in the I2C world. The bus driver reports that the transfer couldn't get through, and then the EEPROM driver knows the details and does something apropriate, probably waiting a while. This assumes that the EEPROM can still play well on the I2C bus. If a faulty device will lock up a bus because of bad microcode while it is busy, then it surely needs handling of that :( And this convinces me just more that it should be in the driver... > The latter. I never bothered trying to write up a list. Typically the behavior > is not documented and needs to be tweaked a couple of times, and it may be > different across chips supported by the same driver, or even across chip > revisions. Any list trying to keep track of the various details would > be difficult to maintain and notoriously be outdated. ... especially because of that. If there is really some repeating pattern for some of the devices, we could introduce helper functions for the drivers to use maybe. But the I2C core functions are not the place to handle it. All the best, Wolfram signature.asc Description: PGP signature
Re: [PATCH v1 0/2] [PATCH] hwmon: (pmbus/max31785) Add minimum delay between bus accesses
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 > > later suggested prepare_device() callback[2] sounds better to me. I > > still haven't fully understood why this all cannot be handled in the > > driver's probe. Could someone give me a small summary about that? > > > > Lots of PMBus devices have the same problem, we have always handled > it in PMBus drivers by implementing local wait code, and your references > point that out. I am confused now. Reading your reply: "I am not sure if an implementation in the i2c core is desirable. It looks quite invasive to me, and it won't solve the problem for all devices since it isn't always a simple "wait microseconds between accesses". For example, some devices may require a wait after a write but not after a read, or a wait only after certain commands (such as commands writing to an EEPROM)." I get the impression you don't prefer to have a generic mechanism in the I2C core. This I share. Your response now sounds like you do support that idea now? > What other summary are you looking for ? What the actual problem is with these devices. The cover letter only mentions "issues with small command turn-around times". More details would be nice. Is it between transfers? Or even between messages within one transfer? Has it been tried to lower the bus frequency? Stuff like this. > On a side note, if anyone plans to implement the prepare_device() callback, > please make sure that it covers all requirements. It would be unfortunate > if such a callback was implemented if that would still require per-driver > code (besides the callback). Is there a list of that somewhere? Or does it mean going through all the drivers and see what they currently do? Regards, Wolfram signature.asc Description: PGP signature
Re: [PATCH v1 0/2] [PATCH] hwmon: (pmbus/max31785) Add minimum delay between bus accesses
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 suggested prepare_device() callback[2] sounds better to me. I still haven't fully understood why this all cannot be handled in the driver's probe. Could someone give me a small summary about that? All the best, Wolfram [1] https://lore.kernel.org/all/e7a64983-fe1d-1ba2-b0c3-ae4a791f7...@roeck-us.net/ [2] https://lore.kernel.org/all/120342ec-f44a-4550-8c54-45b97db41...@www.fastmail.com/ signature.asc Description: PGP signature
[PATCH] drm: tilcdc: don't use devm_pinctrl_get_select_default() in probe
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/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 9aefd010acde..68093d6b6b16 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -6,7 +6,6 @@
#include
#include
-#include
#include
#include
@@ -308,7 +307,6 @@ static int panel_probe(struct platform_device *pdev)
struct backlight_device *backlight;
struct panel_module *panel_mod;
struct tilcdc_module *mod;
- struct pinctrl *pinctrl;
int ret;
/* bail out early if no DT data: */
@@ -342,10 +340,6 @@ static int panel_probe(struct platform_device *pdev)
tilcdc_module_init(mod, "panel", _module_ops);
- pinctrl = devm_pinctrl_get_select_default(>dev);
- if (IS_ERR(pinctrl))
- dev_warn(>dev, "pins are not configured\n");
-
panel_mod->timings = of_get_display_timings(node);
if (!panel_mod->timings) {
dev_err(>dev, "could not get panel timings\n");
--
2.30.2
[PATCH v2] drm: renesas: rcar-du: use proper naming for R-Car
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/renesas/rcar-du/rcar_du_plane.h b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h index f9893d7d6dfc..e9e59c5e70d5 100644 --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h @@ -16,7 +16,7 @@ struct rcar_du_format_info; struct rcar_du_group; /* - * The RCAR DU has 8 hardware planes, shared between primary and overlay planes. + * The R-Car DU has 8 hardware planes, shared between primary and overlay planes. * As using overlay planes requires at least one of the CRTCs being enabled, no * more than 7 overlay planes can be available. We thus create 1 primary plane * per CRTC and 7 overlay planes, for a total of up to 9 KMS planes. -- 2.35.1
[PATCH] drm: renesas: rcar-du: use proper naming for R-Car
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..e9e59c5e70d5 100644 --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h @@ -16,7 +16,7 @@ struct rcar_du_format_info; struct rcar_du_group; /* - * The RCAR DU has 8 hardware planes, shared between primary and overlay planes. + * The R-Car DU has 8 hardware planes, shared between primary and overlay planes. * As using overlay planes requires at least one of the CRTCs being enabled, no * more than 7 overlay planes can be available. We thus create 1 primary plane * per CRTC and 7 overlay planes, for a total of up to 9 KMS planes. -- 2.35.1
Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
> > 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 particular case, why do you consider this a hack? I previously suggested the solution that the PMIC driver exposes a clock to be consumed for the RTC driver even for the "two DT node solution". Because it then avoids a custom property with a phandle to the other node with regular DT clock bindings. I'd think we need sth like that in any case. signature.asc Description: PGP signature
Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
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* handles more than one address. Everything else has been handled differently in the past (for all the uses I am aware of). Yet, I have another idea which is so simple that I wonder if it maybe has already been discussed so far? * have two regs in the bindings * use the second reg with i2c_new_client_device to instantiate the RTC sibling. 'struct i2c_board_info', which is one parameter, should have enough options to pass data, e.g it has a software_node. Should work or did I miss something here? Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
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 unconditionally? > > Thinking more about this: DT is hardware description, so the RTC should > > always be described in DT. If the RTC is actually activated is more a > > configuration thing, or? Brainstorming: maybe the PMIC driver could try > > to find the node with reg == 0x6f and see if firmware has enabled it or > > not? > > I guess the RTC part would acknowledge anyway? > It is always present, it is just part of the RAA215300. I mean the driver should scan for the DT node. Not on the bus. But a phandle is probably safer. > Sure, you can put that in DT. But it's a pity you have to do that, > as the device (the PMIC part) does know the revision... > That's why I suggested to let the PMIC part instantiate an i2c ancillary > device... I see. I'll let it sink in some more. Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
Hi Biju,
> DT-Maintainers suggestion:
> [1]
> raa215300: pmic@12 {
> compatible = "renesas,raa215300";
> reg = <0x12>, <0x6f>;
> reg-names = "main", "rtc";
>
> clocks = <>;
> clock-names = "xin";
> /* Add Optional shared IRQ resource and share it to child and handle it
> both in parent and child */
> };
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?
>
> Laurent/Wolfram suggestion to split it into two nodes and get rid of this
> patch:
> [2]
> raa215300: pmic @12 {
> compatible = "renesas,raa215300";
> reg = <0x12>;
>
> /* Add Optional shared IRQ */
> renesas,raa215300-rtc = <_raa215300>; /* Parse the handle
> and Enable RTC , if present.*/
Thinking more about this: DT is hardware description, so the RTC should
always be described in DT. If the RTC is actually activated is more a
configuration thing, or? Brainstorming: maybe the PMIC driver could try
to find the node with reg == 0x6f and see if firmware has enabled it or
not?
> };
>
> rtc_raa215300: rtc@6f {
> compatible = "renesas,raa215300-isl1208";
> reg = <0x6f>;
>
> /* Add Optional shared IRQ */
> clocks = <>;
> clock-names = "xin";
> renesas,raa215300-pmic = <>; /* Parse the handle to get
> PMIC version to check Oscillator bit is inverted or not */
> };
I have been scratching my head around this and wondered about one thing.
The RTC driver needs to know if the oscillator bit is inverted. AFAIU
this depends on the version of the PMIC (which includes the RTC). So,
can't we simply encode the version in the compatible string?
> compatible = "renesas,raa215300-isl1208-01";
> compatible = "renesas,raa215300-isl1208-a0";
I dunno the exact versions, but you probably get the idea.
Happy hacking,
Wolfram
signature.asc
Description: PGP signature
Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
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 have devices bundling two features into the same chip. I recall at least RTC + EEPROM somewhere. And so far, we have been handling this by creating two nodes in DT and have proper binding docs. I think this is cleaner. First, you can see in DT already what the compound device really consists of. In this case, which RTC and RTC driver is exactly needed. Second, the code added here adds complexity to the I2C core with another layer of inderection for dummy devices. > As some resources are shared (knowledge about the clocks), splitting > this in two distinct devices in DT (which is what Biju's initial patch > series did) would need phandles to link both nodes together. > > Do you have a better idea how to represent this? Not sure if I understood this chip correctly, but maybe: The PMIC driver exposes a clock gate which can be consumed by the RTC driver? Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
> Wolfram: time to chime in ;-) I'll have a look this week. signature.asc Description: PGP signature
[PATCH v2] drm: rcar-du: remove R-Car H3 ES1.* workarounds
R-Car H3 ES1.* was only available to an internal development group and
needed a lot of quirks and workarounds. These become a maintenance
burden now, so our development group decided to remove upstream support
for this SoC and prevent booting it. Public users only have ES2 onwards.
Signed-off-by: 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
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 37 ++--
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 48 --
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 3 +-
4 files changed, 4 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index d6d29be6b4f4..7e175dbfd892 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -223,20 +223,6 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
* DU channels that have a display PLL can't use the internal
* system clock, and have no internal clock divider.
*/
-
- /*
-* The H3 ES1.x exhibits dot clock duty cycle stability issues.
-* We can work around them by configuring the DPLL to twice the
-* desired frequency, coupled with a /2 post-divider. Restrict
-* the workaround to H3 ES1.x as ES2.0 and all other SoCs have
-* no post-divider when a display PLL is present (as shown by
-* the workaround breaking HDMI output on M3-W during testing).
-*/
- if (rcdu->info->quirks & RCAR_DU_QUIRK_H3_ES1_PCLK_STABILITY) {
- target *= 2;
- div = 1;
- }
-
extclk = clk_get_rate(rcrtc->extclock);
rcar_du_dpll_divider(rcrtc, , extclk, target);
@@ -245,30 +231,13 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
| DPLLCR_N(dpll.n) | DPLLCR_M(dpll.m)
| DPLLCR_STBY;
- if (rcrtc->index == 1) {
+ if (rcrtc->index == 1)
dpllcr |= DPLLCR_PLCS1
| DPLLCR_INCS_DOTCLKIN1;
- } else {
- dpllcr |= DPLLCR_PLCS0_PLL
+ else
+ dpllcr |= DPLLCR_PLCS0
| DPLLCR_INCS_DOTCLKIN0;
- /*
-* On ES2.x we have a single mux controlled via bit 21,
-* which selects between DCLKIN source (bit 21 = 0) and
-* a PLL source (bit 21 = 1), where the PLL is always
-* PLL1.
-*
-* On ES1.x we have an additional mux, controlled
-* via bit 20, for choosing between PLL0 (bit 20 = 0)
-* and PLL1 (bit 20 = 1). We always want to use PLL1,
-* so on ES1.x, in addition to setting bit 21, we need
-* to set the bit 20.
-*/
-
- if (rcdu->info->quirks & RCAR_DU_QUIRK_H3_ES1_PLL)
- dpllcr |= DPLLCR_PLCS0_H3ES1X_PLL1;
- }
-
rcar_du_group_write(rcrtc->group, DPLLCR, dpllcr);
escr = ESCR_DCLKSEL_DCLKIN | div;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index b9a94c5260e9..1ffde19cb87f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
@@ -387,43 +386,6 @@ static const struct rcar_du_device_info
rcar_du_r8a7795_info = {
.dpll_mask = BIT(2) | BIT(1),
};
-static const struct rcar_du_device_info rcar_du_r8a7795_es1_info = {
- .gen = 3,
- .features = RCAR_DU_FEATURE_CRTC_IRQ
- | RCAR_DU_FEATURE_CRTC_CLOCK
- | RCAR_DU_FEATURE_VSP1_SOURCE
- | RCAR_DU_FEATURE_INTERLACED
- | RCAR_DU_FEATURE_TVM_SYNC,
- .quirks = RCAR_DU_QUIRK_H3_ES1_PCLK_STABILITY
- | RCAR_DU_QUIRK_H3_ES1_PLL,
- .channels_mask = BIT(3) | BIT(2) | BIT(1) | BIT(0),
- .routes = {
- /*
-* R8A7795 has one RGB output, two HDMI outputs and one
-* LVDS output.
-*/
- [RCAR_DU_OUTPUT_DPAD0] = {
- .possible_crtcs = BIT(3),
-
[PATCH 00/11] tree-wide: remove support for Renesas R-Car H3 ES1
Because H3 ES1 becomes an increasing maintenance burden and was only available to a development group, we decided to remove upstream support for it. Here are the patches to remove driver changes. Review tags have been gathered before during an internal discussion. Only change since the internal version is a plain rebase to v6.3-rc1. A branch with all removals is here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/h3es1-removal Please apply individually per subsystem. There are no dependencies and the SoC doesn't boot anymore since v6.3-rc1. Thanks and happy hacking! 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 thermal/drivers/rcar_gen3_thermal: remove R-Car H3 ES1.* handling ravb: remove R-Car H3 ES1.* handling mmc: renesas_sdhi: remove R-Car H3 ES1.* handling usb: host: xhci-rcar: remove leftover quirk handling usb: host: xhci-rcar: remove R-Car H3 ES1.* handling usb: gadget: udc: renesas_usb3: remove R-Car H3 ES1.* handling drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 37 ++--- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 48 - drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 - drivers/gpu/drm/rcar-du/rcar_du_regs.h| 3 +- drivers/iommu/ipmmu-vmsa.c| 1 - .../platform/renesas/rcar-vin/rcar-core.c | 36 - .../platform/renesas/rcar-vin/rcar-csi2.c | 15 ++ drivers/media/platform/renesas/rcar_fdp1.c| 4 -- drivers/mmc/host/renesas_sdhi_internal_dmac.c | 10 ++-- drivers/net/ethernet/renesas/ravb_main.c | 15 -- drivers/thermal/rcar_gen3_thermal.c | 52 +-- drivers/usb/gadget/udc/renesas_usb3.c | 23 +--- drivers/usb/host/xhci-rcar.c | 34 +--- 13 files changed, 16 insertions(+), 264 deletions(-) -- 2.35.1
[PATCH 02/11] drm: rcar-du: remove R-Car H3 ES1.* workarounds
R-Car H3 ES1.* was only available to an internal development group and
needed a lot of quirks and workarounds. These become a maintenance
burden now, so our development group decided to remove upstream support
and disable booting for this SoC. Public users only have ES2 onwards.
Signed-off-by: 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/rcar-du/rcar_du_drv.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 3 +-
4 files changed, 4 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 008e172ed43b..84411c452e30 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -223,20 +223,6 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
* DU channels that have a display PLL can't use the internal
* system clock, and have no internal clock divider.
*/
-
- /*
-* The H3 ES1.x exhibits dot clock duty cycle stability issues.
-* We can work around them by configuring the DPLL to twice the
-* desired frequency, coupled with a /2 post-divider. Restrict
-* the workaround to H3 ES1.x as ES2.0 and all other SoCs have
-* no post-divider when a display PLL is present (as shown by
-* the workaround breaking HDMI output on M3-W during testing).
-*/
- if (rcdu->info->quirks & RCAR_DU_QUIRK_H3_ES1_PCLK_STABILITY) {
- target *= 2;
- div = 1;
- }
-
extclk = clk_get_rate(rcrtc->extclock);
rcar_du_dpll_divider(rcrtc, , extclk, target);
@@ -245,30 +231,13 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
| DPLLCR_N(dpll.n) | DPLLCR_M(dpll.m)
| DPLLCR_STBY;
- if (rcrtc->index == 1) {
+ if (rcrtc->index == 1)
dpllcr |= DPLLCR_PLCS1
| DPLLCR_INCS_DOTCLKIN1;
- } else {
- dpllcr |= DPLLCR_PLCS0_PLL
+ else
+ dpllcr |= DPLLCR_PLCS0
| DPLLCR_INCS_DOTCLKIN0;
- /*
-* On ES2.x we have a single mux controlled via bit 21,
-* which selects between DCLKIN source (bit 21 = 0) and
-* a PLL source (bit 21 = 1), where the PLL is always
-* PLL1.
-*
-* On ES1.x we have an additional mux, controlled
-* via bit 20, for choosing between PLL0 (bit 20 = 0)
-* and PLL1 (bit 20 = 1). We always want to use PLL1,
-* so on ES1.x, in addition to setting bit 21, we need
-* to set the bit 20.
-*/
-
- if (rcdu->info->quirks & RCAR_DU_QUIRK_H3_ES1_PLL)
- dpllcr |= DPLLCR_PLCS0_H3ES1X_PLL1;
- }
-
rcar_du_group_write(rcrtc->group, DPLLCR, dpllcr);
escr = ESCR_DCLKSEL_DCLKIN | div;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index b9a94c5260e9..1ffde19cb87f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
@@ -387,43 +386,6 @@ static const struct rcar_du_device_info
rcar_du_r8a7795_info = {
.dpll_mask = BIT(2) | BIT(1),
};
-static const struct rcar_du_device_info rcar_du_r8a7795_es1_info = {
- .gen = 3,
- .features = RCAR_DU_FEATURE_CRTC_IRQ
- | RCAR_DU_FEATURE_CRTC_CLOCK
- | RCAR_DU_FEATURE_VSP1_SOURCE
- | RCAR_DU_FEATURE_INTERLACED
- | RCAR_DU_FEATURE_TVM_SYNC,
- .quirks = RCAR_DU_QUIRK_H3_ES1_PCLK_STABILITY
- | RCAR_DU_QUIRK_H3_ES1_PLL,
- .channels_mask = BIT(3) | BIT(2) | BIT(1) | BIT(0),
- .routes = {
- /*
-* R8A7795 has one RGB output, two HDMI outputs and one
-* LVDS output.
-*/
- [RCAR_DU_OUTPUT_DPAD0] = {
- .possible_crtcs = BIT(3),
- .port = 0,
- },
- [RCAR_DU_OUTPUT_HDMI0] = {
- .possible_crtcs = BIT(1),
- .port = 1,
- },
-
Re: [PATCH] dt-bindings: Fix SPI and I2C bus node names in examples
4:33PM -0600, Rob Herring wrote:
> SPI and I2C bus node names are expected to be "spi" or "i2c",
> respectively, with nothing else, a unit-address, or a '-N' index. A
> pattern of 'spi0' or 'i2c0' or similar has crept in. Fix all these
> cases. Mostly scripted with the following commands:
>
> git grep -l '\si2c[0-9] {' Documentation/devicetree/ | xargs sed -i -e
> 's/i2c[0-9] {/i2c {/'
> git grep -l '\sspi[0-9] {' Documentation/devicetree/ | xargs sed -i -e
> 's/spi[0-9] {/spi {/'
>
> 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
Re: remove arch/sh
> 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 effort and congrats on your progress. Looks like you do the right things correctly, cool! Kudos also to Geert and others for their assistance. signature.asc Description: PGP signature
[PATCH] video: move from strlcpy with unused retval to strscpy
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: Wolfram Sang
---
drivers/video/console/sticore.c| 2 +-
drivers/video/fbdev/aty/atyfb_base.c | 2 +-
drivers/video/fbdev/aty/radeon_base.c | 2 +-
drivers/video/fbdev/bw2.c | 2 +-
drivers/video/fbdev/cirrusfb.c | 2 +-
drivers/video/fbdev/clps711x-fb.c | 2 +-
drivers/video/fbdev/core/fbcon.c | 2 +-
drivers/video/fbdev/cyber2000fb.c | 8
drivers/video/fbdev/ffb.c | 2 +-
drivers/video/fbdev/geode/gx1fb_core.c | 6 +++---
drivers/video/fbdev/gxt4500.c | 2 +-
drivers/video/fbdev/i740fb.c | 2 +-
drivers/video/fbdev/imxfb.c| 2 +-
drivers/video/fbdev/matrox/matroxfb_base.c | 6 +++---
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 2 +-
drivers/video/fbdev/pxa168fb.c | 2 +-
drivers/video/fbdev/pxafb.c| 2 +-
drivers/video/fbdev/s3fb.c | 2 +-
drivers/video/fbdev/simplefb.c | 2 +-
drivers/video/fbdev/sis/sis_main.c | 4 ++--
drivers/video/fbdev/sm501fb.c | 2 +-
drivers/video/fbdev/sstfb.c| 2 +-
drivers/video/fbdev/sunxvr1000.c | 2 +-
drivers/video/fbdev/sunxvr2500.c | 2 +-
drivers/video/fbdev/sunxvr500.c| 2 +-
drivers/video/fbdev/tcx.c | 2 +-
drivers/video/fbdev/tdfxfb.c | 4 ++--
drivers/video/fbdev/tgafb.c| 2 +-
drivers/video/fbdev/tridentfb.c| 2 +-
29 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/drivers/video/console/sticore.c b/drivers/video/console/sticore.c
index bd4dc97d4d34..db568f67e4dc 100644
--- a/drivers/video/console/sticore.c
+++ b/drivers/video/console/sticore.c
@@ -290,7 +290,7 @@ static char default_sti_path[21] __read_mostly;
static int __init sti_setup(char *str)
{
if (str)
- strlcpy (default_sti_path, str, sizeof (default_sti_path));
+ strscpy(default_sti_path, str, sizeof(default_sti_path));
return 1;
}
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index a3e6faed7745..14eb718bd67c 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3891,7 +3891,7 @@ static int __init atyfb_setup(char *options)
&& (!strncmp(this_opt, "Mach64:", 7))) {
static unsigned char m64_num;
static char mach64_str[80];
- strlcpy(mach64_str, this_opt + 7, sizeof(mach64_str));
+ strscpy(mach64_str, this_opt + 7, sizeof(mach64_str));
if (!store_video_par(mach64_str, m64_num)) {
m64_num++;
mach64_count = m64_num;
diff --git a/drivers/video/fbdev/aty/radeon_base.c
b/drivers/video/fbdev/aty/radeon_base.c
index 6851f47613e1..73b07c77a4e1 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -1980,7 +1980,7 @@ static int radeon_set_fbinfo(struct radeonfb_info *rinfo)
info->screen_base = rinfo->fb_base;
info->screen_size = rinfo->mapped_vram;
/* Fill fix common fields */
- strlcpy(info->fix.id, rinfo->name, sizeof(info->fix.id));
+ strscpy(info->fix.id, rinfo->name, sizeof(info->fix.id));
info->fix.smem_start = rinfo->fb_base_phys;
info->fix.smem_len = rinfo->video_ram;
info->fix.type = FB_TYPE_PACKED_PIXELS;
diff --git a/drivers/video/fbdev/bw2.c b/drivers/video/fbdev/bw2.c
index e7702fe1fe7d..6403ae07970d 100644
--- a/drivers/video/fbdev/bw2.c
+++ b/drivers/video/fbdev/bw2.c
@@ -182,7 +182,7 @@ static int bw2_ioctl(struct fb_info *info, unsigned int
cmd, unsigned long arg)
static void bw2_init_fix(struct fb_info *info, int linebytes)
{
- strlcpy(info->fix.id, "bwtwo", sizeof(info->fix.id));
+ strscpy(info->fix.id, "bwtwo", sizeof(info->fix.id));
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.visual = FB_VISUAL_MONO01;
diff --git a/drivers/video/fbdev/cirrusfb.c b/drivers/video/fbdev/cirrusfb.c
index a41a75841e10..2a9fa06881b5 100644
--- a/drivers/video/fbdev/cirrusfb.c
+++ b/drivers/video/fbdev/cirrusfb.c
@@ -1999,7 +1999,7 @@ static int cirrusfb_set_fbinfo(struct fb_info *info)
}
/* Fill fix common fields */
- strlcpy(info->fix.id, cirr
[PATCH] dma-buf: move from strlcpy with unused retval to strscpy
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: Wolfram Sang
---
drivers/dma-buf/sw_sync.c | 2 +-
drivers/dma-buf/sync_file.c | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 348b3a9170fa..63f0aeb66db6 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -85,7 +85,7 @@ static struct sync_timeline *sync_timeline_create(const char
*name)
kref_init(>kref);
obj->context = dma_fence_context_alloc(1);
- strlcpy(obj->name, name, sizeof(obj->name));
+ strscpy(obj->name, name, sizeof(obj->name));
obj->pt_tree = RB_ROOT;
INIT_LIST_HEAD(>pt_list);
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 3ebec19a8e02..af57799c86ce 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -132,7 +132,7 @@ EXPORT_SYMBOL(sync_file_get_fence);
char *sync_file_get_name(struct sync_file *sync_file, char *buf, int len)
{
if (sync_file->user_name[0]) {
- strlcpy(buf, sync_file->user_name, len);
+ strscpy(buf, sync_file->user_name, len);
} else {
struct dma_fence *fence = sync_file->fence;
@@ -172,7 +172,7 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
return NULL;
}
sync_file->fence = fence;
- strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
+ strscpy(sync_file->user_name, name, sizeof(sync_file->user_name));
return sync_file;
}
@@ -262,9 +262,9 @@ static long sync_file_ioctl_merge(struct sync_file
*sync_file,
static int sync_fill_fence_info(struct dma_fence *fence,
struct sync_fence_info *info)
{
- strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
+ strscpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
- strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
+ strscpy(info->driver_name, fence->ops->get_driver_name(fence),
sizeof(info->driver_name));
info->status = dma_fence_get_status(fence);
--
2.35.1
[PATCH] gpu: move from strlcpy with unused retval to strscpy
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: Wolfram Sang
---
drivers/gpu/drm/amd/amdgpu/atom.c | 2 +-
drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c | 2 +-
drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 +++---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
drivers/gpu/drm/display/drm_dp_helper.c | 2 +-
drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
drivers/gpu/drm/drm_mipi_dsi.c | 2 +-
drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_perf.c | 2 +-
drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 2 +-
drivers/gpu/drm/radeon/radeon_atombios.c| 4 ++--
drivers/gpu/drm/radeon/radeon_combios.c | 4 ++--
drivers/gpu/drm/rockchip/inno_hdmi.c| 2 +-
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 2 +-
15 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index 1c5d9388ad0b..5f610e9a5f0f 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -1509,7 +1509,7 @@ struct atom_context *amdgpu_atom_parse(struct card_info
*card, void *bios)
str = CSTR(idx);
if (*str != '\0') {
pr_info("ATOM BIOS: %s\n", str);
- strlcpy(ctx->vbios_version, str, sizeof(ctx->vbios_version));
+ strscpy(ctx->vbios_version, str, sizeof(ctx->vbios_version));
}
atom_rom_header = (struct _ATOM_ROM_HEADER *)CSTR(base);
diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
b/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
index d3fe149d8476..81fb4e5dd804 100644
--- a/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
+++ b/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
@@ -794,7 +794,7 @@ void amdgpu_add_thermal_controller(struct amdgpu_device
*adev)
struct i2c_board_info info = { };
const char *name =
pp_lib_thermal_controller_names[controller->ucType];
info.addr = controller->ucI2cAddress >> 1;
- strlcpy(info.type, name, sizeof(info.type));
+ strscpy(info.type, name, sizeof(info.type));
i2c_new_client_device(>pm.i2c_bus->adapter, );
}
} else {
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
index 7d2ed0ed2fe2..4efb62bcdb63 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
@@ -542,8 +542,8 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
- strlcpy(card->driver, DRIVER_NAME, sizeof(card->driver));
- strlcpy(card->shortname, "DW-HDMI", sizeof(card->shortname));
+ strscpy(card->driver, DRIVER_NAME, sizeof(card->driver));
+ strscpy(card->shortname, "DW-HDMI", sizeof(card->shortname));
snprintf(card->longname, sizeof(card->longname),
"%s rev 0x%02x, irq %d", card->shortname, revision,
data->irq);
@@ -561,7 +561,7 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
dw->pcm = pcm;
pcm->private_data = dw;
- strlcpy(pcm->name, DRIVER_NAME, sizeof(pcm->name));
+ strscpy(pcm->name, DRIVER_NAME, sizeof(pcm->name));
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, _dw_hdmi_ops);
/*
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 25a60eb4d67c..4f3ae976e677 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -533,7 +533,7 @@ static struct i2c_adapter *dw_hdmi_i2c_adapter(struct
dw_hdmi *hdmi)
adap->owner = THIS_MODULE;
adap->dev.parent = hdmi->dev;
adap->algo = _hdmi_algorithm;
- strlcpy(adap->name, "DesignWare HDMI", sizeof(adap->name));
+ strscpy(adap->name, "DesignWare HDMI", sizeof(adap->name));
i2c_set_adapdata(adap, hdmi);
ret = i2c_add_adapter(adap);
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index e5bab236b3ae..10a39b36a661 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.
Re: [PATCH v2 0/6] i2c: Make remove callback return void
> 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.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/make_remove_callback_void-immutable Enjoy! signature.asc Description: PGP signature
Re: [PATCH v2 1/6] drm/i2c/sil164: Drop no-op remove function
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.asc Description: PGP signature
Re: [PATCH] i2c: qcom-geni: Fix GPI DMA buffer sync-back
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 to the message after the transfer is done. > > Add missing assignment of dma buffer in geni_i2c_gpi(). > > Set xferred in i2c_put_dma_safe_msg_buf() to true in case of no error to > ensure the sync-back of this dma buffer to the message. > > Signed-off-by: Robin Reckmann Applied to for-current, thanks! signature.asc Description: PGP signature
Re: [PATCH] i2c: qcom-geni: Fix GPI DMA buffer sync-back
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 to the message after the transfer is done. > > Add missing assignment of dma buffer in geni_i2c_gpi(). > > Set xferred in i2c_put_dma_safe_msg_buf() to true in case of no error to > ensure the sync-back of this dma buffer to the message. > > Signed-off-by: Robin Reckmann Thank you! What would be a Fixes tag for this? signature.asc Description: PGP signature
Re: [PATCH] i2c: at91: use dma safe buffers
> 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 that to a high degree. I think it is also less work for you than asking people to rename their variable all the time :) > Going to take a another look at that when I have time. Thank you! signature.asc Description: PGP signature
Re: [PATCH] i2c: at91: use dma safe buffers
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. Frankly, I think the 'dma_buf' regex is a bit too generic. 'dma_buf' seems like a reasonable name to me if some subsystem has to deal with different buffers which can be DMA or non-DMA, like I2C. If you git-grep the tree, you will find it in quite some places. We could now think of renaming the variable to 'dmabuf' but this is a strange and kind of arbitrary rule to remember IMO. I wonder if you'd miss a lot of patches if we remove 'dma_buf' from the regex and keep 'dma_fence' and 'dma_resv'? Or extend it to 'dma_buf_' or 'struct dma_buf'? All the best, Wolfram signature.asc Description: PGP signature
Re: [PATCH v4] i2c: tegra: Add the ACPI support
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! signature.asc Description: PGP signature
Re: [PATCH RFC] virtio: wrap config->reset calls
On Wed, Oct 13, 2021 at 06:55:31AM -0400, Michael S. Tsirkin wrote: > This will enable cleanups down the road. > The idea is to disable cbs, then add "flush_queued_cbs" callback > as a parameter, this way drivers can flush any work > queued after callbacks have been disabled. > > Signed-off-by: Michael S. Tsirkin Acked-by: Wolfram Sang # for I2C changes signature.asc Description: PGP signature
[PATCH 5/9] drm/panfrost: simplify getting .driver_data
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 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index bd9b7be63b0f..fd4309209088 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -400,8 +400,7 @@ void panfrost_device_reset(struct panfrost_device *pfdev)
#ifdef CONFIG_PM
int panfrost_device_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct panfrost_device *pfdev = platform_get_drvdata(pdev);
+ struct panfrost_device *pfdev = dev_get_drvdata(dev);
panfrost_device_reset(pfdev);
panfrost_devfreq_resume(pfdev);
@@ -411,8 +410,7 @@ int panfrost_device_resume(struct device *dev)
int panfrost_device_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct panfrost_device *pfdev = platform_get_drvdata(pdev);
+ struct panfrost_device *pfdev = dev_get_drvdata(dev);
if (!panfrost_job_is_idle(pfdev))
return -EBUSY;
--
2.30.2
[PATCH 4/9] drm/msm: simplify getting .driver_data
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/disp/mdp5/mdp5_kms.c | 6 ++
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++
drivers/gpu/drm/msm/dsi/dsi_host.c | 6 ++
drivers/gpu/drm/msm/msm_drv.c| 3 +--
5 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ae48f41821cf..32410bd299e7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1185,16 +1185,15 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
static void dpu_unbind(struct device *dev, struct device *master, void *data)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+ struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
struct dss_module_power *mp = _kms->mp;
msm_dss_put_clk(mp->clk_config, mp->num_clk);
- devm_kfree(>dev, mp->clk_config);
+ devm_kfree(dev, mp->clk_config);
mp->num_clk = 0;
if (dpu_kms->rpm_enabled)
- pm_runtime_disable(>dev);
+ pm_runtime_disable(dev);
}
static const struct component_ops dpu_ops = {
@@ -1216,8 +1215,7 @@ static int dpu_dev_remove(struct platform_device *pdev)
static int __maybe_unused dpu_runtime_suspend(struct device *dev)
{
int i, rc = -1;
- struct platform_device *pdev = to_platform_device(dev);
- struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+ struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
struct dss_module_power *mp = _kms->mp;
/* Drop the performance state vote */
@@ -1235,8 +1233,7 @@ static int __maybe_unused dpu_runtime_suspend(struct
device *dev)
static int __maybe_unused dpu_runtime_resume(struct device *dev)
{
int rc = -1;
- struct platform_device *pdev = to_platform_device(dev);
- struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+ struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
struct drm_encoder *encoder;
struct drm_device *ddev;
struct dss_module_power *mp = _kms->mp;
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index b3b42672b2d4..3db9d1603dfe 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -1015,8 +1015,7 @@ static int mdp5_dev_remove(struct platform_device *pdev)
static __maybe_unused int mdp5_runtime_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
+ struct mdp5_kms *mdp5_kms = dev_get_drvdata(dev);
DBG("");
@@ -1025,8 +1024,7 @@ static __maybe_unused int mdp5_runtime_suspend(struct
device *dev)
static __maybe_unused int mdp5_runtime_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
+ struct mdp5_kms *mdp5_kms = dev_get_drvdata(dev);
DBG("");
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index fbe4c2cd52a3..a58fccacc874 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1272,8 +1272,7 @@ static int dp_display_remove(struct platform_device *pdev)
static int dp_pm_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct msm_dp *dp_display = platform_get_drvdata(pdev);
+ struct msm_dp *dp_display = dev_get_drvdata(dev);
struct dp_display_private *dp;
int sink_count = 0;
@@ -1329,8 +1328,7 @@ static int dp_pm_resume(struct device *dev)
static int dp_pm_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct msm_dp *dp_display = platform_get_drvdata(pdev);
+ struct msm_dp *dp_display = dev_get_drvdata(dev);
struct dp_display_private *dp;
dp = container_of(dp_display, struct dp_display_private, dp_display);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index e269df285136..d27db5777f2c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -470,8 +470,7 @@ static void dsi_bus_clk_disable(struct msm_dsi_host
*msm_host)
int msm_dsi_runtime_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct msm_dsi *msm_dsi = platform_get_drvdata(pdev);
+ struct msm_dsi *msm_dsi = dev_get_drvdata(dev
[PATCH 0/9] treewide: simplify getting .driver_data
I got tired of fixing this in Renesas drivers manually, so I took the big hammer. Remove this cumbersome code pattern which got copy-pasted too much already: - struct platform_device *pdev = to_platform_device(dev); - struct ep93xx_keypad *keypad = platform_get_drvdata(pdev); + struct ep93xx_keypad *keypad = dev_get_drvdata(dev); A branch, tested by buildbot, can be found here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git coccinelle/get_drvdata I am open for other comments, suggestions, too, of course. Here is the cocci-script I created: @@ struct device* d; identifier pdev; expression *ptr; @@ ( - struct platform_device *pdev = to_platform_device(d); | - struct platform_device *pdev; ... - pdev = to_platform_device(d); ) <... when != pdev - >dev + d ...> ptr = - platform_get_drvdata(pdev) + dev_get_drvdata(d) <... when != pdev - >dev + d ...> Kind regards, Wolfram Wolfram Sang (9): dmaengine: stm32-dmamux: simplify getting .driver_data firmware: meson: simplify getting .driver_data gpio: xilinx: simplify getting .driver_data drm/msm: simplify getting .driver_data drm/panfrost: simplify getting .driver_data iio: common: cros_ec_sensors: simplify getting .driver_data net: mdio: mdio-bcm-iproc: simplify getting .driver_data platform: chrome: cros_ec_sensorhub: simplify getting .driver_data remoteproc: omap_remoteproc: simplify getting .driver_data drivers/dma/stm32-dmamux.c | 14 +- drivers/firmware/meson/meson_sm.c | 3 +-- drivers/gpio/gpio-xilinx.c | 6 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 13 + drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 6 ++ drivers/gpu/drm/msm/dp/dp_display.c| 6 ++ drivers/gpu/drm/msm/dsi/dsi_host.c | 6 ++ drivers/gpu/drm/msm/msm_drv.c | 3 +-- drivers/gpu/drm/panfrost/panfrost_device.c | 6 ++ .../common/cros_ec_sensors/cros_ec_sensors_core.c | 3 +-- drivers/net/mdio/mdio-bcm-iproc.c | 3 +-- drivers/platform/chrome/cros_ec_sensorhub.c| 6 ++ drivers/remoteproc/omap_remoteproc.c | 6 ++ 13 files changed, 28 insertions(+), 53 deletions(-) -- 2.30.2
Re: [PATCH] drivers: i2c: i2c-core-smbus.c: Fix alignment of comment
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 still not comments as they should be according to the kernel coding style. If we touch it, we should make it proper. Also, please use 'git log' to check how the $subject line should be in this subsystem. signature.asc Description: PGP signature
Re: [PATCH] dt-bindings: Drop redundant minItems/maxItems
On Tue, Jun 15, 2021 at 01:15:43PM -0600, Rob Herring wrote: > If a property has an 'items' list, then a 'minItems' or 'maxItems' with the > same size as the list is redundant and can be dropped. Note that is DT > schema specific behavior and not standard json-schema behavior. The tooling > will fixup the final schema adding any unspecified minItems/maxItems. > > This condition is partially checked with the meta-schema already, but > only if both 'minItems' and 'maxItems' are equal to the 'items' length. > An improved meta-schema is pending. > > Cc: Jens Axboe > Cc: Stephen Boyd > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: David Airlie > Cc: Daniel Vetter > Cc: Vinod Koul > Cc: Bartosz Golaszewski > Cc: Kamal Dasu > Cc: Jonathan Cameron > Cc: Lars-Peter Clausen > Cc: Thomas Gleixner > Cc: Marc Zyngier > Cc: Joerg Roedel > Cc: Jassi Brar > Cc: Mauro Carvalho Chehab > Cc: Krzysztof Kozlowski > Cc: Ulf Hansson > Cc: Jakub Kicinski > Cc: Wolfgang Grandegger > Cc: Marc Kleine-Budde > Cc: Andrew Lunn > Cc: Vivien Didelot > Cc: Vladimir Oltean > Cc: Bjorn Helgaas > Cc: Kishon Vijay Abraham I > Cc: Linus Walleij > Cc: "Uwe Kleine-König" > Cc: Lee Jones > Cc: Ohad Ben-Cohen > Cc: Mathieu Poirier > Cc: Philipp Zabel > Cc: Paul Walmsley > Cc: 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
Re: linux-next: build failure after merge of the i2c tree
> Hi, this issue is fixed in > https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-gt-next=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 my pull request for the next merge window until drm has landed first. signature.asc Description: PGP signature
Re: linux-next: build failure after merge of the i2c tree
Hi Stephen,
> After merging the i2c tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/gpu/drm/i915/i915_gem.c:1250:
> drivers/gpu/drm/i915/selftests/i915_gem.c:97:13: error: conflicting types for
> 'pm_suspend'
>97 | static void pm_suspend(struct drm_i915_private *i915)
> | ^~
> In file included from include/linux/regulator/consumer.h:35,
> from include/linux/i2c.h:18,
> from drivers/gpu/drm/i915/i915_drv.h:39,
> from drivers/gpu/drm/i915/gt/intel_context.h:14,
> from drivers/gpu/drm/i915/gem/i915_gem_context.h:12,
> from drivers/gpu/drm/i915/i915_gem.c:44:
> include/linux/suspend.h:331:12: note: previous declaration of 'pm_suspend'
> was here
> 331 | extern int pm_suspend(suspend_state_t state);
> |^~
>
> Caused by commit
>
> 5a7b95fb993e ("i2c: core: support bus regulator controlling in adapter")
>
> interacting with commit
>
> 3f51b7e1f36a ("drm/i915/selftests: Add a simple exerciser for
> suspend/hibernate")
>
> from Linus' tree (v4.20-rc1)
Thank you very much for taking care of this!
> I have added the following merge fix patch:
>
> From: Stephen Rothwell
> Date: Tue, 1 Jun 2021 10:25:49 +1000
> Subject: [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
Re: [PATCH v3 4/5] amba: Make the remove callback return void
On Tue, Jan 26, 2021 at 05:58:34PM +0100, Uwe Kleine-König wrote: > All amba drivers return 0 in their remove callback. Together with the > driver core ignoring the return value anyhow, it doesn't make sense to > return a value here. > > Change the remove prototype to return void, which makes it explicit that > returning an error value doesn't work as expected. This simplifies changing > the core remove callback to return void, too. > > Reviewed-by: Ulf Hansson > Reviewed-by: Arnd Bergmann > Acked-by: Alexandre Belloni > Acked-by: Dmitry Torokhov > 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "i2c: qcom-geni: Disable DMA processing on the Lenovo Yoga C630"
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 processing on the Lenovo Yoga C630")'.
>
> Signed-off-by: Bjorn Andersson
> ---
Added another ack from Caleb and applied to for-next, thanks!
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: More whitespace clean-ups in schema files
On Fri, Oct 23, 2020 at 02:22:58PM -0500, Rob Herring wrote: > Clean-up incorrect indentation, extra spaces, and missing EOF newline in > schema files. Most of the clean-ups are for list indentation which > should always be 2 spaces more than the preceding keyword. > > Found with yamllint (now integrated into the checks). > > Cc: linux-arm-ker...@lists.infradead.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-g...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dt-bindings: Add missing 'unevaluatedProperties'
On Mon, Oct 05, 2020 at 01:38:27PM -0500, Rob Herring wrote: > This doesn't yet do anything in the tools, but make it explicit so we can > check either 'unevaluatedProperties' or 'additionalProperties' is present > in schemas. > > 'unevaluatedProperties' is appropriate when including another schema (via > '$ref') and all possible properties and/or child nodes are not > explicitly listed in the schema with the '$ref'. > > This is in preparation to add a meta-schema to check for missing > 'unevaluatedProperties' 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
Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;
> 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) > fallthrough; > case PCI_DEVICE_ID_INTEL_82801CA_3: > priv->features |= FEATURE_HOST_NOTIFY; > - fallthrough; > + break; > case PCI_DEVICE_ID_INTEL_82801BA_2: > case PCI_DEVICE_ID_INTEL_82801AB_3: > case PCI_DEVICE_ID_INTEL_82801AA_3: I am not the maintainer (Jean is) but I suggest to drop this hunk. The code is more complex with multiple 'fallthrough', so this change alone actually makes the code inconsistent. A rework would need a seperate patch. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: Whitespace clean-ups in schema files
On Wed, Aug 12, 2020 at 02:36:18PM -0600, Rob Herring wrote: > Clean-up incorrect indentation, extra spaces, long lines, and missing > EOF newline in schema files. Most of the clean-ups are for list > indentation which should always be 2 spaces more than the preceding > keyword. > > Found with yamllint (which I plan to integrate into the checks). > > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-...@vger.kernel.org > Cc: linux-g...@vger.kernel.org > Cc: linux-remotep...@vger.kernel.org > Cc: linux-hw...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-fb...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-in...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: alsa-de...@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 for touching 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
Re: [PATCH 09/20] Documentation: i2c: eliminate duplicated word
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 mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/20] Documentation: i2c: eliminate duplicated word
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 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Remove handhelds.org links and email addresses
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
patch is about is not comfortable. You can add the link with a Link: tag
for additional information.
Removing stale email addresses may have some value, but removing...
> Compaq's Bootldr + John Dorsey's patch for Assabet support
> -(http://www.handhelds.org/Compaq/bootldr.html)
... information like this is not good. 'Wayback machine' still has
copies in case someone wants to look at where the infos came from.
> - * Copyright 2004-2005 Phil Blundell
> + * Copyright 2004-2005 Phil Blundell
This is an OK case in my book...
> -MODULE_AUTHOR("Phil Blundell ");
> +MODULE_AUTHOR("Phil Blundell");
... same here ...
> @@ -435,7 +435,6 @@
> case a PCI bridge (DEC chip 21152). The value of
> 'pb' is now only initialized if a de4x5 chip is
> present.
> -
This is kind of a signature and should be kept IMO.
> * 2001/07/23:
> - * - Hand merge version from handhelds.org CVS tree. See patch
> + * - Hand merge version from CVS tree. See patch
That information may be useful.
> /* SPDX-License-Identifier: GPL-2.0-only */
> /* -*- linux-c -*-
> - *
> - * (C) 2003 ze...@handhelds.org
Removing copyright is a bad idea.
Probably some comment blocks are cruft meanwhile and can be removed as a
whole. That can be discussed. But removing only the handhelds.org part
makes most parts worse IMHO.
Thanks and happy hacking,
Wolfram
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] remove deprecated i2c_new_device API
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 > is okay for everyone to collect them like this and push them via I2C for > 5.8-rc2. > > One 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. Applied to for-current, thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm: encoder_slave: fix refcouting error for modules
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_encoder_slave.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave.c
b/drivers/gpu/drm/drm_encoder_slave.c
index cf804389f5ec..d50a7884e69e 100644
--- a/drivers/gpu/drm/drm_encoder_slave.c
+++ b/drivers/gpu/drm/drm_encoder_slave.c
@@ -84,7 +84,7 @@ int drm_i2c_encoder_init(struct drm_device *dev,
err = encoder_drv->encoder_init(client, dev, encoder);
if (err)
- goto fail_unregister;
+ goto fail_module_put;
if (info->platform_data)
encoder->slave_funcs->set_config(>base,
@@ -92,9 +92,10 @@ int drm_i2c_encoder_init(struct drm_device *dev,
return 0;
+fail_module_put:
+ module_put(module);
fail_unregister:
i2c_unregister_device(client);
- module_put(module);
fail:
return err;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] video: backlight: tosa_lcd: convert to use i2c_new_client_device()
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 --git a/drivers/video/backlight/tosa_lcd.c
b/drivers/video/backlight/tosa_lcd.c
index e8ab583e5098..113116d3585c 100644
--- a/drivers/video/backlight/tosa_lcd.c
+++ b/drivers/video/backlight/tosa_lcd.c
@@ -107,7 +107,7 @@ static void tosa_lcd_tg_on(struct tosa_lcd_data *data)
/* TG LCD GVSS */
tosa_tg_send(spi, TG_PINICTL, 0x0);
- if (!data->i2c) {
+ if (IS_ERR_OR_NULL(data->i2c)) {
/*
* after the pannel is powered up the first time,
* we can access the i2c bus so probe for the DAC
@@ -119,7 +119,7 @@ static void tosa_lcd_tg_on(struct tosa_lcd_data *data)
.addr = DAC_BASE,
.platform_data = data->spi,
};
- data->i2c = i2c_new_device(adap, );
+ data->i2c = i2c_new_client_device(adap, );
}
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] remove deprecated i2c_new_device API
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 is okay for everyone to collect them like this and push them via I2C for 5.8-rc2. One 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): drm: encoder_slave: fix refcouting error for modules drm: encoder_slave: use new I2C API x86/platform/intel-mid: convert to use i2c_new_client_device() video: backlight: tosa_lcd: convert to use i2c_new_client_device() Documentation: media: convert to use i2c_new_client_device() i2c: remove deprecated i2c_new_device API .../driver-api/media/v4l2-subdev.rst | 2 +- .../userspace-api/media/conf_nitpick.py | 2 +- arch/x86/platform/intel-mid/sfi.c | 4 +-- drivers/gpu/drm/drm_encoder_slave.c | 15 --- drivers/i2c/i2c-core-base.c | 25 --- drivers/video/backlight/tosa_lcd.c| 4 +-- include/linux/i2c.h | 8 +++--- 7 files changed, 14 insertions(+), 46 deletions(-) -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm: encoder_slave: use new I2C API
i2c_new_client() is deprecated, use the replacement
i2c_new_client_device(). Also, we have a helper to check if a driver is
bound. Use it to simplify the code. Note that this changes the errno for
a failed device creation from ENOMEM to ENODEV. No callers currently
interpret this errno, though, so 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.c
b/drivers/gpu/drm/drm_encoder_slave.c
index d50a7884e69e..e464429d32df 100644
--- a/drivers/gpu/drm/drm_encoder_slave.c
+++ b/drivers/gpu/drm/drm_encoder_slave.c
@@ -61,13 +61,8 @@ int drm_i2c_encoder_init(struct drm_device *dev,
request_module("%s%s", I2C_MODULE_PREFIX, info->type);
- client = i2c_new_device(adap, info);
- if (!client) {
- err = -ENOMEM;
- goto fail;
- }
-
- if (!client->dev.driver) {
+ client = i2c_new_client_device(adap, info);
+ if (!i2c_client_has_driver(client)) {
err = -ENODEV;
goto fail_unregister;
}
@@ -96,7 +91,6 @@ int drm_i2c_encoder_init(struct drm_device *dev,
module_put(module);
fail_unregister:
i2c_unregister_device(client);
-fail:
return err;
}
EXPORT_SYMBOL(drm_i2c_encoder_init);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vblank: remove outdated and noisy output
The R-Car DU driver calls drm_vblank_init via some helper functions in
probe(). From what I checked, most drivers do this as well. I have a
config now where DU always stays in deferred_probe state because of a
missing dependency. This means that every time I rebind another driver
like MMC, the 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/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index da7b0b0c1090..ce9bed24c2da 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -483,8 +483,6 @@ int drm_vblank_init(struct drm_device *dev, unsigned int
num_crtcs)
seqlock_init(>seqlock);
}
- DRM_INFO("Supports vblank timestamp caching Rev 2 (21.10.2013).\n");
-
return 0;
err:
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm: encoder_slave: some updates
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. > > Wolfram Sang (2): > drm: encoder_slave: fix refcouting error for modules > drm: encoder_slave: use new I2C API > > drivers/gpu/drm/drm_encoder_slave.c | 15 +-- > 1 file changed, 5 insertions(+), 10 deletions(-) Is there someone I should add to the CC list maybe? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] video: backlight: tosa_lcd: convert to use i2c_new_client_device()
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/video/backlight/tosa_lcd.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > Applied, thanks. Thanks! I don't see it in -next, though? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/91] i2c: brcmstb: Allow to compile it on BCM2835
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...@broadcom.com > Cc: linux-...@vger.kernel.org > Acked-by: Florian Fainelli > Signed-off-by: Maxime Ripard I reconsidered, and took it right away (as simple as it is). Applied to for-next, thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/91] i2c: brcmstb: Allow to compile it on BCM2835
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 || ARCH_BCM_63XX || \ > >> - COMPILE_TEST > >> + depends on ARCH_BCM2835 || ARCH_BRCMSTB || BMIPS_GENERIC || \ > >> + ARCH_BCM_63XX || COMPILE_TEST > > > > Isn't there something like ARCH_BROADCOM which we could use here instead > > of adding each and every SoC? > > If you are worried about this list growing bigger, I do not think this > is going to happen beyond this changeset (famous last words). Okay, thanks for the heads up. I wonder, then, if the description after 'tristate' is still accurate? But that withstanding, I am fine with this patch: Acked-by: Wolfram Sang Let me know if I shall take this via I2C. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/91] i2c: brcmstb: Allow to compile it on BCM2835
> 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't there something like ARCH_BROADCOM which we could use here instead of adding each and every SoC? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: Remove cases of 'allOf' containing a '$ref'
On Wed, Apr 15, 2020 at 07:55:49PM -0500, Rob Herring wrote: > json-schema versions draft7 and earlier have a weird behavior in that > any keywords combined with a '$ref' are ignored (silently). The correct > form was to put a '$ref' under an 'allOf'. This behavior is now changed > in the 2019-09 json-schema spec and '$ref' can be mixed with other > keywords. The json-schema library doesn't yet support this, but the > tooling now does a fixup for this and either way works. > > This has been a constant source of review comments, 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 list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: Clean-up schema indentation formatting
On Wed, Apr 15, 2020 at 07:55:48PM -0500, Rob Herring wrote: > Fix various inconsistencies in schema indentation. Most of these are > list indentation which should be 2 spaces more than the start of the > enclosing keyword. This doesn't matter functionally, but affects running > 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.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: Remove cases of 'allOf' containing a '$ref'
On Wed, Apr 15, 2020 at 07:55:49PM -0500, Rob Herring wrote: > json-schema versions draft7 and earlier have a weird behavior in that > any keywords combined with a '$ref' are ignored (silently). The correct > form was to put a '$ref' under an 'allOf'. This behavior is now changed > in the 2019-09 json-schema spec and '$ref' can be mixed with other > keywords. The json-schema library doesn't yet support this, but the > tooling now does a fixup for this and either way works. > > This has been a constant source of review comments, 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
Re: [PATCH 1/2] dt-bindings: Clean-up schema indentation formatting
On Wed, Apr 15, 2020 at 07:55:48PM -0500, Rob Herring wrote: > Fix various inconsistencies in schema indentation. Most of these are > list indentation which should be 2 spaces more than the start of the > enclosing keyword. This doesn't matter functionally, but affects running > 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.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/radeon: convert to use i2c_new_client_device()
> > > > 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 through whatever tree makes sense. I'd suggest drm-misc-next to minimize merge conflicts. But I can take it via I2C tree, too, if desired. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] gpu: convert to use new I2C API
We are deprecating calls which return NULL in favor of new variants which return an ERR_PTR. Only build tested. Wolfram Sang (6): drm/amdgpu: convert to use i2c_new_client_device() drm/gma500: convert to use i2c_new_client_device() drm/i2c/sil164: convert to use i2c_new_client_device() drm/i2c/tda998x: convert to use i2c_new_client_device() drm/nouveau/therm: convert to use i2c_new_client_device() drm/radeon: convert to use i2c_new_client_device() drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c| 2 +- drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 8 drivers/gpu/drm/i2c/sil164_drv.c | 7 +-- drivers/gpu/drm/i2c/tda998x_drv.c | 6 +++--- drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c | 4 ++-- drivers/gpu/drm/radeon/radeon_atombios.c | 4 ++-- drivers/gpu/drm/radeon/radeon_combios.c| 4 ++-- 7 files changed, 19 insertions(+), 16 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/radeon: convert to use i2c_new_client_device()
Move away from the deprecated API.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/radeon/radeon_atombios.c | 4 ++--
drivers/gpu/drm/radeon/radeon_combios.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 848ef68d9086..5d2591725189 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -2111,7 +2111,7 @@ static int radeon_atombios_parse_power_table_1_3(struct
radeon_device *rdev)
ucOverdriveThermalController];
info.addr =
power_info->info.ucOverdriveControllerAddress >> 1;
strlcpy(info.type, name, sizeof(info.type));
- i2c_new_device(>pm.i2c_bus->adapter, );
+ i2c_new_client_device(>pm.i2c_bus->adapter,
);
}
}
num_modes = power_info->info.ucNumOfPowerModeEntries;
@@ -2351,7 +2351,7 @@ static void
radeon_atombios_add_pplib_thermal_controller(struct radeon_device *r
const char *name =
pp_lib_thermal_controller_names[controller->ucType];
info.addr = controller->ucI2cAddress >> 1;
strlcpy(info.type, name, sizeof(info.type));
- i2c_new_device(>pm.i2c_bus->adapter,
);
+
i2c_new_client_device(>pm.i2c_bus->adapter, );
}
} else {
DRM_INFO("Unknown thermal controller type %d at 0x%02x
%s fan control\n",
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index c3e49c973812..d3c04df7e75d 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -2704,7 +2704,7 @@ void radeon_combios_get_power_modes(struct radeon_device
*rdev)
const char *name =
thermal_controller_names[thermal_controller];
info.addr = i2c_addr >> 1;
strlcpy(info.type, name, sizeof(info.type));
- i2c_new_device(>pm.i2c_bus->adapter,
);
+
i2c_new_client_device(>pm.i2c_bus->adapter, );
}
}
} else {
@@ -2721,7 +2721,7 @@ void radeon_combios_get_power_modes(struct radeon_device
*rdev)
const char *name = "f75375";
info.addr = 0x28;
strlcpy(info.type, name, sizeof(info.type));
- i2c_new_device(>pm.i2c_bus->adapter,
);
+
i2c_new_client_device(>pm.i2c_bus->adapter, );
DRM_INFO("Possible %s thermal controller at
0x%02x\n",
name, info.addr);
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/nouveau/therm: convert to use i2c_new_client_device()
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c
index 03b355dabab3..abf3eda683f0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c
@@ -36,8 +36,8 @@ probe_monitoring_device(struct nvkm_i2c_bus *bus,
request_module("%s%s", I2C_MODULE_PREFIX, info->type);
- client = i2c_new_device(>i2c, info);
- if (!client)
+ client = i2c_new_client_device(>i2c, info);
+ if (IS_ERR(client))
return false;
if (!client->dev.driver ||
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/i2c/sil164: convert to use i2c_new_client_device()
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/i2c/sil164_drv.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i2c/sil164_drv.c b/drivers/gpu/drm/i2c/sil164_drv.c
index a839f78a4c8a..741886b54419 100644
--- a/drivers/gpu/drm/i2c/sil164_drv.c
+++ b/drivers/gpu/drm/i2c/sil164_drv.c
@@ -393,7 +393,7 @@ sil164_detect_slave(struct i2c_client *client)
return NULL;
}
- return i2c_new_device(adap, );
+ return i2c_new_client_device(adap, );
}
static int
@@ -402,6 +402,7 @@ sil164_encoder_init(struct i2c_client *client,
struct drm_encoder_slave *encoder)
{
struct sil164_priv *priv;
+ struct i2c_client *slave_client;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -410,7 +411,9 @@ sil164_encoder_init(struct i2c_client *client,
encoder->slave_priv = priv;
encoder->slave_funcs = _encoder_funcs;
- priv->duallink_slave = sil164_detect_slave(client);
+ slave_client = sil164_detect_slave(client);
+ if (!IS_ERR(slave_client))
+ priv->duallink_slave = slave_client;
return 0;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/amdgpu: convert to use i2c_new_client_device()
Move away from the deprecated API.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
index ba1bb95a3cf9..0e8018c9aa8e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
@@ -856,7 +856,7 @@ void amdgpu_add_thermal_controller(struct amdgpu_device
*adev)
const char *name =
pp_lib_thermal_controller_names[controller->ucType];
info.addr = controller->ucI2cAddress >> 1;
strlcpy(info.type, name, sizeof(info.type));
- i2c_new_device(>pm.i2c_bus->adapter,
);
+
i2c_new_client_device(>pm.i2c_bus->adapter, );
}
} else {
DRM_INFO("Unknown thermal controller type %d at 0x%02x
%s fan control\n",
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/1] video: convert to use new I2C API
We are deprecating calls which return NULL in favor of new variants which return an ERR_PTR. Only build tested. Wolfram Sang (1): video: backlight: tosa_lcd: convert to use i2c_new_client_device() drivers/video/backlight/tosa_lcd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/i2c/tda998x: convert to use i2c_new_client_device()
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/i2c/tda998x_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index c3332209f27a..d9a548d0273c 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1949,9 +1949,9 @@ static int tda998x_create(struct device *dev)
cec_info.platform_data = >cec_glue;
cec_info.irq = client->irq;
- priv->cec = i2c_new_device(client->adapter, _info);
- if (!priv->cec) {
- ret = -ENODEV;
+ priv->cec = i2c_new_client_device(client->adapter, _info);
+ if (IS_ERR(priv->cec)) {
+ ret = PTR_ERR(priv->cec);
goto fail;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/gma500: convert to use i2c_new_client_device()
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
b/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
index 9e8224456ea2..71574063c63e 100644
--- a/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
+++ b/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
@@ -747,11 +747,11 @@ static int cmi_lcd_hack_create_device(void)
return -EINVAL;
}
- client = i2c_new_device(adapter, );
- if (!client) {
- pr_err("%s: i2c_new_device() failed\n", __func__);
+ client = i2c_new_client_device(adapter, );
+ if (IS_ERR(client)) {
+ pr_err("%s: creating I2C device failed\n", __func__);
i2c_put_adapter(adapter);
- return -EINVAL;
+ return PTR_ERR(client);
}
return 0;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] video: backlight: tosa_lcd: convert to use i2c_new_client_device()
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/video/backlight/tosa_lcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/tosa_lcd.c
b/drivers/video/backlight/tosa_lcd.c
index e8ab583e5098..113116d3585c 100644
--- a/drivers/video/backlight/tosa_lcd.c
+++ b/drivers/video/backlight/tosa_lcd.c
@@ -107,7 +107,7 @@ static void tosa_lcd_tg_on(struct tosa_lcd_data *data)
/* TG LCD GVSS */
tosa_tg_send(spi, TG_PINICTL, 0x0);
- if (!data->i2c) {
+ if (IS_ERR_OR_NULL(data->i2c)) {
/*
* after the pannel is powered up the first time,
* we can access the i2c bus so probe for the DAC
@@ -119,7 +119,7 @@ static void tosa_lcd_tg_on(struct tosa_lcd_data *data)
.addr = DAC_BASE,
.platform_data = data->spi,
};
- data->i2c = i2c_new_device(adap, );
+ data->i2c = i2c_new_client_device(adap, );
}
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: encoder_slave: fix refcouting error for modules
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
---
drivers/gpu/drm/drm_encoder_slave.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave.c
b/drivers/gpu/drm/drm_encoder_slave.c
index cf804389f5ec..d50a7884e69e 100644
--- a/drivers/gpu/drm/drm_encoder_slave.c
+++ b/drivers/gpu/drm/drm_encoder_slave.c
@@ -84,7 +84,7 @@ int drm_i2c_encoder_init(struct drm_device *dev,
err = encoder_drv->encoder_init(client, dev, encoder);
if (err)
- goto fail_unregister;
+ goto fail_module_put;
if (info->platform_data)
encoder->slave_funcs->set_config(>base,
@@ -92,9 +92,10 @@ int drm_i2c_encoder_init(struct drm_device *dev,
return 0;
+fail_module_put:
+ module_put(module);
fail_unregister:
i2c_unregister_device(client);
- module_put(module);
fail:
return err;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm: encoder_slave: some updates
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. Wolfram Sang (2): drm: encoder_slave: fix refcouting error for modules drm: encoder_slave: use new I2C API drivers/gpu/drm/drm_encoder_slave.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: encoder_slave: use new I2C API
i2c_new_client() is deprecated, use the replacement
i2c_new_client_device(). Also, we have a helper to check if a driver is
bound. Use it to simplify the code. Note that this changes the errno for
a failed device creation from ENOMEM to ENODEV. No callers currently
interpret this errno, though, so we use this condensed error check.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/drm_encoder_slave.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave.c
b/drivers/gpu/drm/drm_encoder_slave.c
index d50a7884e69e..e464429d32df 100644
--- a/drivers/gpu/drm/drm_encoder_slave.c
+++ b/drivers/gpu/drm/drm_encoder_slave.c
@@ -61,13 +61,8 @@ int drm_i2c_encoder_init(struct drm_device *dev,
request_module("%s%s", I2C_MODULE_PREFIX, info->type);
- client = i2c_new_device(adap, info);
- if (!client) {
- err = -ENOMEM;
- goto fail;
- }
-
- if (!client->dev.driver) {
+ client = i2c_new_client_device(adap, info);
+ if (!i2c_client_has_driver(client)) {
err = -ENODEV;
goto fail_unregister;
}
@@ -96,7 +91,6 @@ int drm_i2c_encoder_init(struct drm_device *dev,
module_put(module);
fail_unregister:
i2c_unregister_device(client);
-fail:
return err;
}
EXPORT_SYMBOL(drm_i2c_encoder_init);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/89] i2c: brcmstb: Allow to compile it on BCM2835
> config I2C_BRCMSTB > tristate "BRCM Settop/DSL I2C controller" > depends on ARCH_BRCMSTB || BMIPS_GENERIC || ARCH_BCM_63XX || \ > -COMPILE_TEST > +COMPILE_TEST || ARCH_BCM2835 Can you please sort if for easier maintenance? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/89] i2c: brcmstb: Support BCM2711 HDMI BSC controllers
On Mon, Feb 24, 2020 at 10:06:05AM +0100, Maxime Ripard wrote: > The HDMI blocks in the BCM2771 have an i2c controller to retrieve the > EDID. This block is split into two parts, the BSC and the AUTO_I2C, > lying in two separate register areas. > > The AUTO_I2C block has a mailbox-like interface and will take away the > BSC control from the CPU if enabled. However, the BSC is the actually > the same controller than the one supported by the brcmstb driver, and > the AUTO_I2C doesn't really bring any immediate benefit. > > Let's use the BSC then, but let's also tie the AUTO_I2C registers with a > separate compatible so that we can enable AUTO_I2C if needed in the > future. > > The AUTO_I2C is enabled by default at boot though, so we first need to > release the BSC from the AUTO_I2C control. > > Cc: Kamal Dasu > Cc: Florian Fainelli > Cc: Wolfram Sang > Cc: bcm-kernel-feedback-l...@broadcom.com > Cc: linux-...@vger.kernel.org > Signed-off-by: Maxime Ripard Fixed the acked-by and applied to for-next, thanks! FYI, cppcheck rightfully warned about this in the driver: drivers/i2c/busses/i2c-brcmstb.c:319:7: warning: Condition 'CMD_RD' is always true [knownConditionTrueFalse] if ((CMD_RD || CMD_WR) && ^ drivers/i2c/busses/i2c-brcmstb.c:319:17: warning: Condition 'CMD_WR' is always false [knownConditionTrueFalse] if ((CMD_RD || CMD_WR) && ^ drivers/i2c/busses/i2c-brcmstb.c:464:0: warning: Variable 'len' is assigned a value that is never used. [unreadVariable] int len = 0; Not related to this patch, but maybe one of you is interested... signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/89] dt-bindings: i2c: brcmstb: Convert the BRCMSTB binding to a schema
On Mon, Feb 24, 2020 at 10:06:03AM +0100, Maxime Ripard wrote: > Switch the DT binding to a YAML schema to enable the DT validation. > > Cc: Kamal Dasu > Cc: Florian Fainelli > Cc: Rob Herring > Cc: Wolfram Sang > Cc: bcm-kernel-feedback-l...@broadcom.com > Cc: linux-...@vger.kernel.org > Cc: devicet...@vger.kernel.org > Signed-off-by: Maxime Ripard Applied to for-next, thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/89] dt-bindings: i2c: brcmstb: Add BCM2711 BSC/AUTO-I2C binding
On Mon, Feb 24, 2020 at 10:06:04AM +0100, Maxime Ripard wrote: > The HDMI blocks in the BCM2771 have an i2c controller to retrieve the > EDID. This block is split into two parts, the BSC and the AUTO_I2C, > lying in two separate register areas. > > The AUTO_I2C block has a mailbox-like interface and will take away the > BSC control from the CPU if enabled. However, the BSC is the actually > the same controller than the one supported by the brcmstb driver, and > the AUTO_I2C doesn't really bring any immediate benefit. > > We can model it in the DT as a single device with two register range, > which will allow us to use or or the other in the driver without > changing anything in the DT. > > Cc: Kamal Dasu > Cc: Florian Fainelli > Cc: Rob Herring > Cc: Wolfram Sang > Cc: bcm-kernel-feedback-l...@broadcom.com > Cc: linux-...@vger.kernel.org > Cc: devicet...@vger.kernel.org > Signed-off-by: Maxime Ripard Applied to for-next, thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/89] dt-bindings: i2c: brcmstb: Convert the BRCMSTB binding to a schema
On Mon, Feb 24, 2020 at 10:06:03AM +0100, Maxime Ripard wrote: > Switch the DT binding to a YAML schema to enable the DT validation. > > Cc: Kamal Dasu > Cc: Florian Fainelli > Cc: Rob Herring > Cc: Wolfram Sang > Cc: bcm-kernel-feedback-l...@broadcom.com > Cc: linux-...@vger.kernel.org > Cc: devicet...@vger.kernel.org > Signed-off-by: Maxime Ripard I didn't get the cover letter, so I assume I shall pick the I2C patches. Please let me have the cover letter next time. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i2c: jz4780: silence log flood on txabrt
On Wed, Feb 12, 2020 at 10:46:28AM +0100, Wolfram Sang wrote: > > The printout for txabrt is way too talkative. Reduce it to the minimum, > the rest can be gained by I2C core debugging and datasheet information. > Also, make it a debug printout, it won't help the regular user. > > Reported-by: H. Nikolaus Schaller > Signed-off-by: Wolfram Sang Applied to for-current, thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i2c: jz4780: silence log flood on txabrt
Hi, > > Sorry, normally I don't do counter patches. Yet, this time I realized > > that it would be faster to actually do what I envisioned than to > > describe it in words. I hope you don't feel offended. > > No problem. I had thought a little about that myself, but did not > dare to solve more than my problem... Glad you like it. Well, it still kinda solves your problem only, because there are still too many dev_err in there, but I think this is good enough for now. > > Obviously, I can't test, does it work for you? > > Yes,it works. Good! > Do you want to push your patch yourself, or should I add it to my > patch series and resubmit in a v2? I'll apply the patch to my tree directly as a bugfix for 5.6. You can drop the I2C list from V2 then. Thanks and kind regards, Wolfram signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
i2c: jz4780: silence log flood on txabrt
The printout for txabrt is way too talkative. Reduce it to the minimum,
the rest can be gained by I2C core debugging and datasheet information.
Also, make it a debug printout, it won't help the regular user.
Reported-by: H. Nikolaus Schaller
Signed-off-by: Wolfram Sang
---
Sorry, normally I don't do counter patches. Yet, this time I realized
that it would be faster to actually do what I envisioned than to
describe it in words. I hope you don't feel offended. This driver has
way too many dev_err anyhow, so this may be a start.
Obviously, I can't test, does it work for you?
drivers/i2c/busses/i2c-jz4780.c | 36 ++---
1 file changed, 2 insertions(+), 34 deletions(-)
diff --git a/drivers/i2c/busses/i2c-jz4780.c b/drivers/i2c/busses/i2c-jz4780.c
index 16a67a64284a..b426fc956938 100644
--- a/drivers/i2c/busses/i2c-jz4780.c
+++ b/drivers/i2c/busses/i2c-jz4780.c
@@ -78,25 +78,6 @@
#define X1000_I2C_DC_STOP BIT(9)
-static const char * const jz4780_i2c_abrt_src[] = {
- "ABRT_7B_ADDR_NOACK",
- "ABRT_10ADDR1_NOACK",
- "ABRT_10ADDR2_NOACK",
- "ABRT_XDATA_NOACK",
- "ABRT_GCALL_NOACK",
- "ABRT_GCALL_READ",
- "ABRT_HS_ACKD",
- "SBYTE_ACKDET",
- "ABRT_HS_NORSTRT",
- "SBYTE_NORSTRT",
- "ABRT_10B_RD_NORSTRT",
- "ABRT_MASTER_DIS",
- "ARB_LOST",
- "SLVFLUSH_TXFIFO",
- "SLV_ARBLOST",
- "SLVRD_INTX",
-};
-
#define JZ4780_I2C_INTST_IGC BIT(11)
#define JZ4780_I2C_INTST_ISTT BIT(10)
#define JZ4780_I2C_INTST_ISTP BIT(9)
@@ -576,21 +557,8 @@ static irqreturn_t jz4780_i2c_irq(int irqno, void *dev_id)
static void jz4780_i2c_txabrt(struct jz4780_i2c *i2c, int src)
{
- int i;
-
- dev_err(>adap.dev, "txabrt: 0x%08x\n", src);
- dev_err(>adap.dev, "device addr=%x\n",
- jz4780_i2c_readw(i2c, JZ4780_I2C_TAR));
- dev_err(>adap.dev, "send cmd count:%d %d\n",
- i2c->cmd, i2c->cmd_buf[i2c->cmd]);
- dev_err(>adap.dev, "receive data count:%d %d\n",
- i2c->cmd, i2c->data_buf[i2c->cmd]);
-
- for (i = 0; i < 16; i++) {
- if (src & BIT(i))
- dev_dbg(>adap.dev, "I2C TXABRT[%d]=%s\n",
- i, jz4780_i2c_abrt_src[i]);
- }
+ dev_dbg(>adap.dev, "txabrt: 0x%08x, cmd: %d, send: %d, recv: %d\n",
+ src, i2c->cmd, i2c->cmd_buf[i2c->cmd], i2c->data_buf[i2c->cmd]);
}
static inline int jz4780_i2c_xfer_read(struct jz4780_i2c *i2c,
--
2.20.1
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 05/12] video: fbdev: matrox: convert to i2c_new_scanned_device
On Thu, Nov 07, 2019 at 09:33:54AM +0100, Daniel Vetter wrote: > On Wed, Nov 06, 2019 at 10:50:23AM +0100, Wolfram Sang wrote: > > Move from the deprecated i2c_new_probed_device() to the new > > i2c_new_scanned_device(). Make use of the new ERRPTR if suitable. > > > > Signed-off-by: Wolfram Sang > > Ack for merging through whatever tree you think this should best land > through. Ok, because it is a single and simple patch, I'll apply it simply via I2C. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 05/12] video: fbdev: matrox: convert to i2c_new_scanned_device
On Wed, Nov 06, 2019 at 10:50:23AM +0100, Wolfram Sang wrote: > Move from the deprecated i2c_new_probed_device() to the new > i2c_new_scanned_device(). Make use of the new ERRPTR if suitable. > > Signed-off-by: Wolfram Sang Applied to for-next, thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 00/12] i2c: replace i2c_new_probed_device with an ERR_PTR variant
From: Wolfram Sang In the on-going mission to let i2c_new_* calls return an ERR_PTR instead of NULL, here is a series converting i2c_new_probed_device(). A new function called i2c_new_scanned_device() is introduced with the new retval, but for now, a compatibility helper is provided until all users are converted. The rest of the patches convert all current in-tree users. Note that these patches are RFC because I want feedback on the approach and hopefully collect acks on the driver conversions. If all goes well, I'll apply the first two patches for the next merge window. Then, once this dependency is upstream, I'll resend this series with all issues fixed and acks collected. Core changes tested on a Renesas Salvator-XS board (R-Car M3-N), driver patches build tested by me and buildbot. Wolfram Sang (12): i2c: replace i2c_new_probed_device with an ERR_PTR variant i2c: icy: convert to i2c_new_scanned_device macintosh: convert to i2c_new_scanned_device platform: chrome: convert to i2c_new_scanned_device video: fbdev: matrox: convert to i2c_new_scanned_device input: mouse: convert to i2c_new_scanned_device media: pci: cx23885: convert to i2c_new_scanned_device media: pci: cx88: convert to i2c_new_scanned_device media: pci: bt8xx: convert to i2c_new_scanned_device media: pci: cx18: convert to i2c_new_scanned_device media: pci: ivtv: convert to i2c_new_scanned_device media: v4l2-core: convert to i2c_new_scanned_device Documentation/i2c/instantiating-devices.rst | 10 - Documentation/i2c/writing-clients.rst | 8 +++ drivers/i2c/busses/i2c-icy.c| 8 +++ drivers/i2c/i2c-core-base.c | 25 - drivers/input/mouse/psmouse-smbus.c | 8 --- drivers/macintosh/therm_windtunnel.c| 4 ++-- drivers/media/pci/bt8xx/bttv-input.c| 6 ++--- drivers/media/pci/cx18/cx18-i2c.c | 2 +- drivers/media/pci/cx23885/cx23885-i2c.c | 4 ++-- drivers/media/pci/cx88/cx88-input.c | 2 +- drivers/media/pci/ivtv/ivtv-i2c.c | 6 ++--- drivers/media/pci/ivtv/ivtv-i2c.h | 2 +- drivers/media/v4l2-core/v4l2-i2c.c | 10 - drivers/platform/chrome/chromeos_laptop.c | 18 --- drivers/video/fbdev/matrox/i2c-matroxfb.c | 4 ++-- include/linux/i2c.h | 12 +++--- 16 files changed, 76 insertions(+), 53 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 05/12] video: fbdev: matrox: convert to i2c_new_scanned_device
Move from the deprecated i2c_new_probed_device() to the new
i2c_new_scanned_device(). Make use of the new ERRPTR if suitable.
Signed-off-by: Wolfram Sang
---
Build tested only. RFC, please comment and/or ack, but don't apply yet.
drivers/video/fbdev/matrox/i2c-matroxfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/matrox/i2c-matroxfb.c
b/drivers/video/fbdev/matrox/i2c-matroxfb.c
index 34e2659c3189..e2e4705e3fe0 100644
--- a/drivers/video/fbdev/matrox/i2c-matroxfb.c
+++ b/drivers/video/fbdev/matrox/i2c-matroxfb.c
@@ -191,8 +191,8 @@ static void* i2c_matroxfb_probe(struct matrox_fb_info*
minfo) {
0x1b, I2C_CLIENT_END
};
- i2c_new_probed_device(>maven.adapter,
- _info, addr_list, NULL);
+ i2c_new_scanned_device(>maven.adapter,
+ _info, addr_list, NULL);
}
}
return m2info;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] gpu: drm: bridge: sii9234: convert to devm_i2c_new_dummy_device
Move from the deprecated i2c_new_dummy() to devm_i2c_new_dummy_device().
We now get an ERRPTR which we use in error handling and we can skip
removal of the created devices.
Signed-off-by: Wolfram Sang
---
Rebased to v5.4-rc2 since last time. One of the last two users of the
old API, so please apply soon, so I can remove the old interface. Only
build tested.
drivers/gpu/drm/bridge/sii9234.c | 36 +++-
1 file changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c
index 25d4ad8c7ad6..8a6c85693a88 100644
--- a/drivers/gpu/drm/bridge/sii9234.c
+++ b/drivers/gpu/drm/bridge/sii9234.c
@@ -841,39 +841,28 @@ static int sii9234_init_resources(struct sii9234 *ctx,
ctx->client[I2C_MHL] = client;
- ctx->client[I2C_TPI] = i2c_new_dummy(adapter, I2C_TPI_ADDR);
- if (!ctx->client[I2C_TPI]) {
+ ctx->client[I2C_TPI] = devm_i2c_new_dummy_device(>dev, adapter,
+I2C_TPI_ADDR);
+ if (IS_ERR(ctx->client[I2C_TPI])) {
dev_err(ctx->dev, "failed to create TPI client\n");
- return -ENODEV;
+ return PTR_ERR(ctx->client[I2C_TPI]);
}
- ctx->client[I2C_HDMI] = i2c_new_dummy(adapter, I2C_HDMI_ADDR);
- if (!ctx->client[I2C_HDMI]) {
+ ctx->client[I2C_HDMI] = devm_i2c_new_dummy_device(>dev, adapter,
+ I2C_HDMI_ADDR);
+ if (IS_ERR(ctx->client[I2C_HDMI])) {
dev_err(ctx->dev, "failed to create HDMI RX client\n");
- goto fail_tpi;
+ return PTR_ERR(ctx->client[I2C_HDMI]);
}
- ctx->client[I2C_CBUS] = i2c_new_dummy(adapter, I2C_CBUS_ADDR);
- if (!ctx->client[I2C_CBUS]) {
+ ctx->client[I2C_CBUS] = devm_i2c_new_dummy_device(>dev, adapter,
+ I2C_CBUS_ADDR);
+ if (IS_ERR(ctx->client[I2C_CBUS])) {
dev_err(ctx->dev, "failed to create CBUS client\n");
- goto fail_hdmi;
+ return PTR_ERR(ctx->client[I2C_CBUS]);
}
return 0;
-
-fail_hdmi:
- i2c_unregister_device(ctx->client[I2C_HDMI]);
-fail_tpi:
- i2c_unregister_device(ctx->client[I2C_TPI]);
-
- return -ENODEV;
-}
-
-static void sii9234_deinit_resources(struct sii9234 *ctx)
-{
- i2c_unregister_device(ctx->client[I2C_CBUS]);
- i2c_unregister_device(ctx->client[I2C_HDMI]);
- i2c_unregister_device(ctx->client[I2C_TPI]);
}
static inline struct sii9234 *bridge_to_sii9234(struct drm_bridge *bridge)
@@ -950,7 +939,6 @@ static int sii9234_remove(struct i2c_client *client)
sii9234_cable_out(ctx);
drm_bridge_remove(>bridge);
- sii9234_deinit_resources(ctx);
return 0;
}
--
2.20.1
[PATCH RESEND] gpu: drm: bridge: analogix-anx78xx: convert to i2c_new_dummy_device
Move from the deprecated i2c_new_dummy() to i2c_new_dummy_device(). We
now get an ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Rebased to v5.4-rc2 since last time. One of the last two users of the
old API, so please apply soon, so I can remove the old interface. Only
build tested.
drivers/gpu/drm/bridge/analogix-anx78xx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index 3c7cc5af735c..be7756280e41 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1350,10 +1350,10 @@ static int anx78xx_i2c_probe(struct i2c_client *client,
/* Map slave addresses of ANX7814 */
for (i = 0; i < I2C_NUM_ADDRESSES; i++) {
- anx78xx->i2c_dummy[i] = i2c_new_dummy(client->adapter,
+ anx78xx->i2c_dummy[i] = i2c_new_dummy_device(client->adapter,
anx78xx_i2c_addresses[i] >> 1);
- if (!anx78xx->i2c_dummy[i]) {
- err = -ENOMEM;
+ if (IS_ERR(anx78xx->i2c_dummy[i])) {
+ err = PTR_ERR(anx78xx->i2c_dummy[i]);
DRM_ERROR("Failed to reserve I2C bus %02x\n",
anx78xx_i2c_addresses[i]);
goto err_unregister_i2c;
--
2.20.1
Re: [BACKPORT 4.14.y 00/18] Backport candidate from TI 4.14 product kernel
On Thu, Sep 05, 2019 at 10:17:41AM -0600, Mathieu Poirier wrote: > These patches are backport candidates picked out of TI's 4.14.y tree [1], > with most of them already found in the 4.19.y stable tree. Could you please update your scripting that only the cover-letter and I2C related patches will be sent to the I2C mailing list? signature.asc Description: PGP signature
[PATCH] video: backlight: tosa_lcd: drop check because i2c_unregister_device() is NULL safe
No need to check the argument of i2c_unregister_device() because the
function itself does it.
Signed-off-by: Wolfram Sang
---
Build tested only, buildbot is happy, too.
Please apply to your tree.
drivers/video/backlight/tosa_lcd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/backlight/tosa_lcd.c
b/drivers/video/backlight/tosa_lcd.c
index 65cb7578776f..29af8e27b6e5 100644
--- a/drivers/video/backlight/tosa_lcd.c
+++ b/drivers/video/backlight/tosa_lcd.c
@@ -222,8 +222,7 @@ static int tosa_lcd_remove(struct spi_device *spi)
{
struct tosa_lcd_data *data = spi_get_drvdata(spi);
- if (data->i2c)
- i2c_unregister_device(data->i2c);
+ i2c_unregister_device(data->i2c);
tosa_lcd_tg_off(data);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] i2c: replace i2c_new_secondary_device with an ERR_PTR variant
On Fri, Aug 09, 2019 at 05:40:47PM +0200, Wolfram Sang wrote: > In the general move to have i2c_new_*_device functions which return > ERR_PTR instead of NULL, this patch converts i2c_new_secondary_device(). > > There are only few users, so this patch converts the I2C core and all > users in one go. The function gets renamed to i2c_new_ancillary_device() > so out-of-tree users will get a build failure to understand they need to > adapt their error checking code. > > Signed-off-by: Wolfram Sang > Reviewed-by: Kieran Bingham # > adv748x > Reviewed-by: Laurent Pinchart # adv7511 Applied to for-next, thanks! signature.asc Description: PGP signature
