Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
On Wed, Dec 13, 2023 at 12:44:34PM +0100, Thierry Reding wrote: > On Wed, Dec 13, 2023 at 11:42:45AM +0200, Svyatoslav Ryhel wrote: > > > > > > 15 листопада 2023 р. 21:11:49 GMT+02:00, Tom Rini > > написав(-ла): > > >On Wed, Nov 15, 2023 at 04:51:08PM +0100, Thierry Reding wrote: > > >> On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote: > > >> > On Mon, Nov 06, 2023 at 02:11:16PM +, Peter Robinson wrote: > > >> > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel > > >> > > wrote: > > >> > > > > > >> > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson > > >> > > > пише: > > >> > > > > > > >> > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel > > >> > > > > wrote: > > >> > > > > > > > >> > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson > > >> > > > > > пише: > > >> > > > > > > > > >> > > > > > > Hi Svyatoslav, > > >> > > > > > > > > >> > > > > > > > Since the proposed PMIC patches have been accepted, I see > > >> > > > > > > > the need > > >> > > > > > > > to convert boards which I maintain to use DM drivers > > >> > > > > > > > instead of board hacks. > > >> > > > > > > > > > >> > > > > > > > Svyatoslav Ryhel (5): > > >> > > > > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > >> > > > > > > > board: endeavoru: convert HTC One X to use DM PMIC > > >> > > > > > > > > >> > > > > > > Is there a reason why the two above devices don't appear to > > >> > > > > > > have their > > >> > > > > > > .dts files in the upstream kernel? > > >> > > > > > > > > >> > > > > > > > >> > > > > > Yes, there is a reason. Linux maintainers treat submitters as > > >> > > > > > existential enemies or as dirt at least. I was trying to work > > >> > > > > > with > > >> > > > > > linux but I have no desire to spend any time to upstream > > >> > > > > > endeavoru or > > >> > > > > > lg_x3. > > >> > > > > > > >> > > > > The usual policy for acceptance into U-Boot is to have upstream > > >> > > > > review > > >> > > > > in the kernel first. > > >> > > > > > > >> > > > > > >> > > > May you point to a policy which clearly and explicitly states this > > >> > > > as > > >> > > > a mandatory condition? > > >> > > > > >> > > There have been a number of devices rejected in the past until their > > >> > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:, > > >> > > to clarify the exact policy. > > >> > > > >> > Well, here is where it's tricky. I brought this up for one of the > > >> > Broadcom MIPS platforms a week or two back, and Linus Walleij's point > > >> > (and I'm paraphrasing) is there's not really an upstream for it to go. > > >> > > > >> > What we cannot have is device tree bindings[1] that aren't upstream or > > >> > worse yet conflict with the official bindings. > > >> > > > >> > So the general way to resolve that is have device tree file be drop-in > > >> > from the linux kernel, and what additions we must have be done via > > >> > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in > > >> > sync with the kernel than other SoCs are. > > >> > > > >> > Now, upstream being actively hostile to dts files, especially for older > > >> > platforms? That's unfortunate. So long as we aren't violating the rules > > >> > about bindings, the intention is that we don't have device trees that > > >> > are either (a) massively out of sync with the kernel[2] or (b) kept > > >> > intentionally mismatched from the kernel. > > >> > > > >> > -- > > >> > Tom > > >> > > > >> > [1]: There are both examples like binman that Simon is working on at > > >> > least but this is more exception than intentional rule. > > >> > [2]: Per our other conversions, I know the tegra ones are in this > > >> > unfortunate state in general > > >> > > >> On the Tegra side we've been fairly lax about the device trees in > > >> U-Boot, I suppose. The assumption had always been that U-Boot would load > > >> an external DTB and pass it to the kernel on boot, so keeping them both > > >> in sync was never a high priority. > > >> > > >> U-Boot does only a very tiny amount of what Linux does, so dropping in > > >> the kernel DTB always seemed a bit overkill. > > >> > > >> In either case, if this is problematic, it's something that I could take > > >> a look at. Again, it's expected that the device trees are different, for > > >> historical reasons, but I'd be surprised if they actually conflict with > > >> one another. U-Boot's DTB was always supposed to be a subset of the > > >> Linux DTB. > > > > > >So, the issue with U-Boot and kernel device trees being out of sync is > > >that we then can't support the model of "just pass the current DT to the > > >OS". This in general is good to support because it means that even if a > > >given platform isn't formally SystemReady IR certified it's still likely > > >to be functional. > > > > > >The most strict rule is that you can't have bindings in U-Boot that > > >conflict with the kernel, or should be in the kernel but aren't, and so >
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
On Wed, Dec 13, 2023 at 11:42:45AM +0200, Svyatoslav Ryhel wrote: > > > 15 листопада 2023 р. 21:11:49 GMT+02:00, Tom Rini > написав(-ла): > >On Wed, Nov 15, 2023 at 04:51:08PM +0100, Thierry Reding wrote: > >> On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote: > >> > On Mon, Nov 06, 2023 at 02:11:16PM +, Peter Robinson wrote: > >> > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel > >> > > wrote: > >> > > > > >> > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson > >> > > > пише: > >> > > > > > >> > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel > >> > > > > wrote: > >> > > > > > > >> > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson > >> > > > > > пише: > >> > > > > > > > >> > > > > > > Hi Svyatoslav, > >> > > > > > > > >> > > > > > > > Since the proposed PMIC patches have been accepted, I see > >> > > > > > > > the need > >> > > > > > > > to convert boards which I maintain to use DM drivers instead > >> > > > > > > > of board hacks. > >> > > > > > > > > >> > > > > > > > Svyatoslav Ryhel (5): > >> > > > > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > >> > > > > > > > board: endeavoru: convert HTC One X to use DM PMIC > >> > > > > > > > >> > > > > > > Is there a reason why the two above devices don't appear to > >> > > > > > > have their > >> > > > > > > .dts files in the upstream kernel? > >> > > > > > > > >> > > > > > > >> > > > > > Yes, there is a reason. Linux maintainers treat submitters as > >> > > > > > existential enemies or as dirt at least. I was trying to work > >> > > > > > with > >> > > > > > linux but I have no desire to spend any time to upstream > >> > > > > > endeavoru or > >> > > > > > lg_x3. > >> > > > > > >> > > > > The usual policy for acceptance into U-Boot is to have upstream > >> > > > > review > >> > > > > in the kernel first. > >> > > > > > >> > > > > >> > > > May you point to a policy which clearly and explicitly states this as > >> > > > a mandatory condition? > >> > > > >> > > There have been a number of devices rejected in the past until their > >> > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:, > >> > > to clarify the exact policy. > >> > > >> > Well, here is where it's tricky. I brought this up for one of the > >> > Broadcom MIPS platforms a week or two back, and Linus Walleij's point > >> > (and I'm paraphrasing) is there's not really an upstream for it to go. > >> > > >> > What we cannot have is device tree bindings[1] that aren't upstream or > >> > worse yet conflict with the official bindings. > >> > > >> > So the general way to resolve that is have device tree file be drop-in > >> > from the linux kernel, and what additions we must have be done via > >> > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in > >> > sync with the kernel than other SoCs are. > >> > > >> > Now, upstream being actively hostile to dts files, especially for older > >> > platforms? That's unfortunate. So long as we aren't violating the rules > >> > about bindings, the intention is that we don't have device trees that > >> > are either (a) massively out of sync with the kernel[2] or (b) kept > >> > intentionally mismatched from the kernel. > >> > > >> > -- > >> > Tom > >> > > >> > [1]: There are both examples like binman that Simon is working on at > >> > least but this is more exception than intentional rule. > >> > [2]: Per our other conversions, I know the tegra ones are in this > >> > unfortunate state in general > >> > >> On the Tegra side we've been fairly lax about the device trees in > >> U-Boot, I suppose. The assumption had always been that U-Boot would load > >> an external DTB and pass it to the kernel on boot, so keeping them both > >> in sync was never a high priority. > >> > >> U-Boot does only a very tiny amount of what Linux does, so dropping in > >> the kernel DTB always seemed a bit overkill. > >> > >> In either case, if this is problematic, it's something that I could take > >> a look at. Again, it's expected that the device trees are different, for > >> historical reasons, but I'd be surprised if they actually conflict with > >> one another. U-Boot's DTB was always supposed to be a subset of the > >> Linux DTB. > > > >So, the issue with U-Boot and kernel device trees being out of sync is > >that we then can't support the model of "just pass the current DT to the > >OS". This in general is good to support because it means that even if a > >given platform isn't formally SystemReady IR certified it's still likely > >to be functional. > > > >The most strict rule is that you can't have bindings in U-Boot that > >conflict with the kernel, or should be in the kernel but aren't, and so > >on. > > > > So you say that U-Boot should support only components which have linux > driver? May you clarify? I think Tom is referring specifically to the bindings only. While it's certainly preferable to have drivers in Linux for all bindings, that's never been a strict
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
15 листопада 2023 р. 21:11:49 GMT+02:00, Tom Rini написав(-ла): >On Wed, Nov 15, 2023 at 04:51:08PM +0100, Thierry Reding wrote: >> On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote: >> > On Mon, Nov 06, 2023 at 02:11:16PM +, Peter Robinson wrote: >> > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel >> > > wrote: >> > > > >> > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson пише: >> > > > > >> > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel >> > > > > wrote: >> > > > > > >> > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson >> > > > > > пише: >> > > > > > > >> > > > > > > Hi Svyatoslav, >> > > > > > > >> > > > > > > > Since the proposed PMIC patches have been accepted, I see the >> > > > > > > > need >> > > > > > > > to convert boards which I maintain to use DM drivers instead >> > > > > > > > of board hacks. >> > > > > > > > >> > > > > > > > Svyatoslav Ryhel (5): >> > > > > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC >> > > > > > > > board: endeavoru: convert HTC One X to use DM PMIC >> > > > > > > >> > > > > > > Is there a reason why the two above devices don't appear to have >> > > > > > > their >> > > > > > > .dts files in the upstream kernel? >> > > > > > > >> > > > > > >> > > > > > Yes, there is a reason. Linux maintainers treat submitters as >> > > > > > existential enemies or as dirt at least. I was trying to work with >> > > > > > linux but I have no desire to spend any time to upstream endeavoru >> > > > > > or >> > > > > > lg_x3. >> > > > > >> > > > > The usual policy for acceptance into U-Boot is to have upstream >> > > > > review >> > > > > in the kernel first. >> > > > > >> > > > >> > > > May you point to a policy which clearly and explicitly states this as >> > > > a mandatory condition? >> > > >> > > There have been a number of devices rejected in the past until their >> > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:, >> > > to clarify the exact policy. >> > >> > Well, here is where it's tricky. I brought this up for one of the >> > Broadcom MIPS platforms a week or two back, and Linus Walleij's point >> > (and I'm paraphrasing) is there's not really an upstream for it to go. >> > >> > What we cannot have is device tree bindings[1] that aren't upstream or >> > worse yet conflict with the official bindings. >> > >> > So the general way to resolve that is have device tree file be drop-in >> > from the linux kernel, and what additions we must have be done via >> > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in >> > sync with the kernel than other SoCs are. >> > >> > Now, upstream being actively hostile to dts files, especially for older >> > platforms? That's unfortunate. So long as we aren't violating the rules >> > about bindings, the intention is that we don't have device trees that >> > are either (a) massively out of sync with the kernel[2] or (b) kept >> > intentionally mismatched from the kernel. >> > >> > -- >> > Tom >> > >> > [1]: There are both examples like binman that Simon is working on at >> > least but this is more exception than intentional rule. >> > [2]: Per our other conversions, I know the tegra ones are in this >> > unfortunate state in general >> >> On the Tegra side we've been fairly lax about the device trees in >> U-Boot, I suppose. The assumption had always been that U-Boot would load >> an external DTB and pass it to the kernel on boot, so keeping them both >> in sync was never a high priority. >> >> U-Boot does only a very tiny amount of what Linux does, so dropping in >> the kernel DTB always seemed a bit overkill. >> >> In either case, if this is problematic, it's something that I could take >> a look at. Again, it's expected that the device trees are different, for >> historical reasons, but I'd be surprised if they actually conflict with >> one another. U-Boot's DTB was always supposed to be a subset of the >> Linux DTB. > >So, the issue with U-Boot and kernel device trees being out of sync is >that we then can't support the model of "just pass the current DT to the >OS". This in general is good to support because it means that even if a >given platform isn't formally SystemReady IR certified it's still likely >to be functional. > >The most strict rule is that you can't have bindings in U-Boot that >conflict with the kernel, or should be in the kernel but aren't, and so >on. > So you say that U-Boot should support only components which have linux driver? May you clarify?
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
On Mon, Dec 11, 2023 at 12:55:32PM +0100, Thierry Reding wrote: > On Wed, Nov 15, 2023 at 02:11:49PM -0500, Tom Rini wrote: > > On Wed, Nov 15, 2023 at 04:51:08PM +0100, Thierry Reding wrote: > > > On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote: > > > > On Mon, Nov 06, 2023 at 02:11:16PM +, Peter Robinson wrote: > > > > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel > > > > > wrote: > > > > > > > > > > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson > > > > > > пише: > > > > > > > > > > > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel > > > > > > > wrote: > > > > > > > > > > > > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson > > > > > > > > пише: > > > > > > > > > > > > > > > > > > Hi Svyatoslav, > > > > > > > > > > > > > > > > > > > Since the proposed PMIC patches have been accepted, I see > > > > > > > > > > the need > > > > > > > > > > to convert boards which I maintain to use DM drivers > > > > > > > > > > instead of board hacks. > > > > > > > > > > > > > > > > > > > > Svyatoslav Ryhel (5): > > > > > > > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > > > > > > > > > board: endeavoru: convert HTC One X to use DM PMIC > > > > > > > > > > > > > > > > > > Is there a reason why the two above devices don't appear to > > > > > > > > > have their > > > > > > > > > .dts files in the upstream kernel? > > > > > > > > > > > > > > > > > > > > > > > > > Yes, there is a reason. Linux maintainers treat submitters as > > > > > > > > existential enemies or as dirt at least. I was trying to work > > > > > > > > with > > > > > > > > linux but I have no desire to spend any time to upstream > > > > > > > > endeavoru or > > > > > > > > lg_x3. > > > > > > > > > > > > > > The usual policy for acceptance into U-Boot is to have upstream > > > > > > > review > > > > > > > in the kernel first. > > > > > > > > > > > > > > > > > > > May you point to a policy which clearly and explicitly states this > > > > > > as > > > > > > a mandatory condition? > > > > > > > > > > There have been a number of devices rejected in the past until their > > > > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:, > > > > > to clarify the exact policy. > > > > > > > > Well, here is where it's tricky. I brought this up for one of the > > > > Broadcom MIPS platforms a week or two back, and Linus Walleij's point > > > > (and I'm paraphrasing) is there's not really an upstream for it to go. > > > > > > > > What we cannot have is device tree bindings[1] that aren't upstream or > > > > worse yet conflict with the official bindings. > > > > > > > > So the general way to resolve that is have device tree file be drop-in > > > > from the linux kernel, and what additions we must have be done via > > > > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in > > > > sync with the kernel than other SoCs are. > > > > > > > > Now, upstream being actively hostile to dts files, especially for older > > > > platforms? That's unfortunate. So long as we aren't violating the rules > > > > about bindings, the intention is that we don't have device trees that > > > > are either (a) massively out of sync with the kernel[2] or (b) kept > > > > intentionally mismatched from the kernel. > > > > > > > > -- > > > > Tom > > > > > > > > [1]: There are both examples like binman that Simon is working on at > > > > least but this is more exception than intentional rule. > > > > [2]: Per our other conversions, I know the tegra ones are in this > > > > unfortunate state in general > > > > > > On the Tegra side we've been fairly lax about the device trees in > > > U-Boot, I suppose. The assumption had always been that U-Boot would load > > > an external DTB and pass it to the kernel on boot, so keeping them both > > > in sync was never a high priority. > > > > > > U-Boot does only a very tiny amount of what Linux does, so dropping in > > > the kernel DTB always seemed a bit overkill. > > > > > > In either case, if this is problematic, it's something that I could take > > > a look at. Again, it's expected that the device trees are different, for > > > historical reasons, but I'd be surprised if they actually conflict with > > > one another. U-Boot's DTB was always supposed to be a subset of the > > > Linux DTB. > > > > So, the issue with U-Boot and kernel device trees being out of sync is > > that we then can't support the model of "just pass the current DT to the > > OS". This in general is good to support because it means that even if a > > given platform isn't formally SystemReady IR certified it's still likely > > to be functional. > > This is certainly not something that we ever strived for with Tegra. It > was always very clear that we needed to get the DTB from the same source > as the kernel. The vast majority of what's in the DTB is completely > useless for U-Boot because it simply doesn't support (and doesn't have > to support) a lot of the hardware that Linux
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
On Wed, Nov 15, 2023 at 02:11:49PM -0500, Tom Rini wrote: > On Wed, Nov 15, 2023 at 04:51:08PM +0100, Thierry Reding wrote: > > On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote: > > > On Mon, Nov 06, 2023 at 02:11:16PM +, Peter Robinson wrote: > > > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel > > > > wrote: > > > > > > > > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson > > > > > пише: > > > > > > > > > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel > > > > > > wrote: > > > > > > > > > > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson > > > > > > > пише: > > > > > > > > > > > > > > > > Hi Svyatoslav, > > > > > > > > > > > > > > > > > Since the proposed PMIC patches have been accepted, I see the > > > > > > > > > need > > > > > > > > > to convert boards which I maintain to use DM drivers instead > > > > > > > > > of board hacks. > > > > > > > > > > > > > > > > > > Svyatoslav Ryhel (5): > > > > > > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > > > > > > > > board: endeavoru: convert HTC One X to use DM PMIC > > > > > > > > > > > > > > > > Is there a reason why the two above devices don't appear to > > > > > > > > have their > > > > > > > > .dts files in the upstream kernel? > > > > > > > > > > > > > > > > > > > > > > Yes, there is a reason. Linux maintainers treat submitters as > > > > > > > existential enemies or as dirt at least. I was trying to work with > > > > > > > linux but I have no desire to spend any time to upstream > > > > > > > endeavoru or > > > > > > > lg_x3. > > > > > > > > > > > > The usual policy for acceptance into U-Boot is to have upstream > > > > > > review > > > > > > in the kernel first. > > > > > > > > > > > > > > > > May you point to a policy which clearly and explicitly states this as > > > > > a mandatory condition? > > > > > > > > There have been a number of devices rejected in the past until their > > > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:, > > > > to clarify the exact policy. > > > > > > Well, here is where it's tricky. I brought this up for one of the > > > Broadcom MIPS platforms a week or two back, and Linus Walleij's point > > > (and I'm paraphrasing) is there's not really an upstream for it to go. > > > > > > What we cannot have is device tree bindings[1] that aren't upstream or > > > worse yet conflict with the official bindings. > > > > > > So the general way to resolve that is have device tree file be drop-in > > > from the linux kernel, and what additions we must have be done via > > > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in > > > sync with the kernel than other SoCs are. > > > > > > Now, upstream being actively hostile to dts files, especially for older > > > platforms? That's unfortunate. So long as we aren't violating the rules > > > about bindings, the intention is that we don't have device trees that > > > are either (a) massively out of sync with the kernel[2] or (b) kept > > > intentionally mismatched from the kernel. > > > > > > -- > > > Tom > > > > > > [1]: There are both examples like binman that Simon is working on at > > > least but this is more exception than intentional rule. > > > [2]: Per our other conversions, I know the tegra ones are in this > > > unfortunate state in general > > > > On the Tegra side we've been fairly lax about the device trees in > > U-Boot, I suppose. The assumption had always been that U-Boot would load > > an external DTB and pass it to the kernel on boot, so keeping them both > > in sync was never a high priority. > > > > U-Boot does only a very tiny amount of what Linux does, so dropping in > > the kernel DTB always seemed a bit overkill. > > > > In either case, if this is problematic, it's something that I could take > > a look at. Again, it's expected that the device trees are different, for > > historical reasons, but I'd be surprised if they actually conflict with > > one another. U-Boot's DTB was always supposed to be a subset of the > > Linux DTB. > > So, the issue with U-Boot and kernel device trees being out of sync is > that we then can't support the model of "just pass the current DT to the > OS". This in general is good to support because it means that even if a > given platform isn't formally SystemReady IR certified it's still likely > to be functional. This is certainly not something that we ever strived for with Tegra. It was always very clear that we needed to get the DTB from the same source as the kernel. The vast majority of what's in the DTB is completely useless for U-Boot because it simply doesn't support (and doesn't have to support) a lot of the hardware that Linux supports. One concern that I have with this policy is that for certain devices we may just not be able to do this. Especially with some early OEM devices I recall that they had limited storage for the bootloader. Since the DTB needs to be embedded, a full-blown DTB from Linux might inflate the size
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
On Wed, Nov 15, 2023 at 04:51:08PM +0100, Thierry Reding wrote: > On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote: > > On Mon, Nov 06, 2023 at 02:11:16PM +, Peter Robinson wrote: > > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel > > > wrote: > > > > > > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson пише: > > > > > > > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel > > > > > wrote: > > > > > > > > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson > > > > > > пише: > > > > > > > > > > > > > > Hi Svyatoslav, > > > > > > > > > > > > > > > Since the proposed PMIC patches have been accepted, I see the > > > > > > > > need > > > > > > > > to convert boards which I maintain to use DM drivers instead of > > > > > > > > board hacks. > > > > > > > > > > > > > > > > Svyatoslav Ryhel (5): > > > > > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > > > > > > > board: endeavoru: convert HTC One X to use DM PMIC > > > > > > > > > > > > > > Is there a reason why the two above devices don't appear to have > > > > > > > their > > > > > > > .dts files in the upstream kernel? > > > > > > > > > > > > > > > > > > > Yes, there is a reason. Linux maintainers treat submitters as > > > > > > existential enemies or as dirt at least. I was trying to work with > > > > > > linux but I have no desire to spend any time to upstream endeavoru > > > > > > or > > > > > > lg_x3. > > > > > > > > > > The usual policy for acceptance into U-Boot is to have upstream review > > > > > in the kernel first. > > > > > > > > > > > > > May you point to a policy which clearly and explicitly states this as > > > > a mandatory condition? > > > > > > There have been a number of devices rejected in the past until their > > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:, > > > to clarify the exact policy. > > > > Well, here is where it's tricky. I brought this up for one of the > > Broadcom MIPS platforms a week or two back, and Linus Walleij's point > > (and I'm paraphrasing) is there's not really an upstream for it to go. > > > > What we cannot have is device tree bindings[1] that aren't upstream or > > worse yet conflict with the official bindings. > > > > So the general way to resolve that is have device tree file be drop-in > > from the linux kernel, and what additions we must have be done via > > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in > > sync with the kernel than other SoCs are. > > > > Now, upstream being actively hostile to dts files, especially for older > > platforms? That's unfortunate. So long as we aren't violating the rules > > about bindings, the intention is that we don't have device trees that > > are either (a) massively out of sync with the kernel[2] or (b) kept > > intentionally mismatched from the kernel. > > > > -- > > Tom > > > > [1]: There are both examples like binman that Simon is working on at > > least but this is more exception than intentional rule. > > [2]: Per our other conversions, I know the tegra ones are in this > > unfortunate state in general > > On the Tegra side we've been fairly lax about the device trees in > U-Boot, I suppose. The assumption had always been that U-Boot would load > an external DTB and pass it to the kernel on boot, so keeping them both > in sync was never a high priority. > > U-Boot does only a very tiny amount of what Linux does, so dropping in > the kernel DTB always seemed a bit overkill. > > In either case, if this is problematic, it's something that I could take > a look at. Again, it's expected that the device trees are different, for > historical reasons, but I'd be surprised if they actually conflict with > one another. U-Boot's DTB was always supposed to be a subset of the > Linux DTB. So, the issue with U-Boot and kernel device trees being out of sync is that we then can't support the model of "just pass the current DT to the OS". This in general is good to support because it means that even if a given platform isn't formally SystemReady IR certified it's still likely to be functional. The most strict rule is that you can't have bindings in U-Boot that conflict with the kernel, or should be in the kernel but aren't, and so on. -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote: > On Mon, Nov 06, 2023 at 02:11:16PM +, Peter Robinson wrote: > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel wrote: > > > > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson пише: > > > > > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel > > > > wrote: > > > > > > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson > > > > > пише: > > > > > > > > > > > > Hi Svyatoslav, > > > > > > > > > > > > > Since the proposed PMIC patches have been accepted, I see the need > > > > > > > to convert boards which I maintain to use DM drivers instead of > > > > > > > board hacks. > > > > > > > > > > > > > > Svyatoslav Ryhel (5): > > > > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > > > > > > board: endeavoru: convert HTC One X to use DM PMIC > > > > > > > > > > > > Is there a reason why the two above devices don't appear to have > > > > > > their > > > > > > .dts files in the upstream kernel? > > > > > > > > > > > > > > > > Yes, there is a reason. Linux maintainers treat submitters as > > > > > existential enemies or as dirt at least. I was trying to work with > > > > > linux but I have no desire to spend any time to upstream endeavoru or > > > > > lg_x3. > > > > > > > > The usual policy for acceptance into U-Boot is to have upstream review > > > > in the kernel first. > > > > > > > > > > May you point to a policy which clearly and explicitly states this as > > > a mandatory condition? > > > > There have been a number of devices rejected in the past until their > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:, > > to clarify the exact policy. > > Well, here is where it's tricky. I brought this up for one of the > Broadcom MIPS platforms a week or two back, and Linus Walleij's point > (and I'm paraphrasing) is there's not really an upstream for it to go. > > What we cannot have is device tree bindings[1] that aren't upstream or > worse yet conflict with the official bindings. > > So the general way to resolve that is have device tree file be drop-in > from the linux kernel, and what additions we must have be done via > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in > sync with the kernel than other SoCs are. > > Now, upstream being actively hostile to dts files, especially for older > platforms? That's unfortunate. So long as we aren't violating the rules > about bindings, the intention is that we don't have device trees that > are either (a) massively out of sync with the kernel[2] or (b) kept > intentionally mismatched from the kernel. > > -- > Tom > > [1]: There are both examples like binman that Simon is working on at > least but this is more exception than intentional rule. > [2]: Per our other conversions, I know the tegra ones are in this > unfortunate state in general On the Tegra side we've been fairly lax about the device trees in U-Boot, I suppose. The assumption had always been that U-Boot would load an external DTB and pass it to the kernel on boot, so keeping them both in sync was never a high priority. U-Boot does only a very tiny amount of what Linux does, so dropping in the kernel DTB always seemed a bit overkill. In either case, if this is problematic, it's something that I could take a look at. Again, it's expected that the device trees are different, for historical reasons, but I'd be surprised if they actually conflict with one another. U-Boot's DTB was always supposed to be a subset of the Linux DTB. Thierry signature.asc Description: PGP signature
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
On Mon, Nov 13, 2023 at 04:52:22PM +, Peter Robinson wrote: > > > > > > > > Since the proposed PMIC patches have been accepted, I see the > > > > > > > > need > > > > > > > > to convert boards which I maintain to use DM drivers instead of > > > > > > > > board hacks. > > > > > > > > > > > > > > > > Svyatoslav Ryhel (5): > > > > > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > > > > > > > board: endeavoru: convert HTC One X to use DM PMIC > > > > > > > > > > > > > > Is there a reason why the two above devices don't appear to have > > > > > > > their > > > > > > > .dts files in the upstream kernel? > > > > > > > > > > > > > > > > > > > Yes, there is a reason. Linux maintainers treat submitters as > > > > > > existential enemies or as dirt at least. I was trying to work with > > > > > > linux but I have no desire to spend any time to upstream endeavoru > > > > > > or > > > > > > lg_x3. > > > > > > > > > > The usual policy for acceptance into U-Boot is to have upstream review > > > > > in the kernel first. > > > > > > > > > > > > > May you point to a policy which clearly and explicitly states this as > > > > a mandatory condition? > > > > > > There have been a number of devices rejected in the past until their > > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:, > > > to clarify the exact policy. > > > > Well, here is where it's tricky. I brought this up for one of the > > Broadcom MIPS platforms a week or two back, and Linus Walleij's point > > (and I'm paraphrasing) is there's not really an upstream for it to go. > > > > What we cannot have is device tree bindings[1] that aren't upstream or > > worse yet conflict with the official bindings. > > > > So the general way to resolve that is have device tree file be drop-in > > from the linux kernel, and what additions we must have be done via > > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in > > sync with the kernel than other SoCs are. > > > > Now, upstream being actively hostile to dts files, especially for older > > platforms? That's unfortunate. So long as we aren't violating the rules > > about bindings, the intention is that we don't have device trees that > > are either (a) massively out of sync with the kernel[2] or (b) kept > > intentionally mismatched from the kernel. > > I don't believe I've seen upstream Tegra maintainers being actively > hostile towards updates for older devices, I know they have certainly > defocused them, but I'm not sure that's what I'd consider hostile. No objections from me on upstreaming older devices in Linux. I used to be able to test most of the older devices, but many of which I used to have direct access to are now defunct (for varying reasons). So I will have to rely on the community for testing etc. since I cannot scale to the point where I personally have all of these devices. Now, I don't think that's hostile and if I ever came across as hostile I'm sorry. The intent was never to reject device support. Obviously the Linux kernel has high standards and sometimes that can be off-putting, but I don't think we've ever asked for anything out of the ordinary. Thierry signature.asc Description: PGP signature
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
> > > > > > > Since the proposed PMIC patches have been accepted, I see the need > > > > > > > to convert boards which I maintain to use DM drivers instead of > > > > > > > board hacks. > > > > > > > > > > > > > > Svyatoslav Ryhel (5): > > > > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > > > > > > board: endeavoru: convert HTC One X to use DM PMIC > > > > > > > > > > > > Is there a reason why the two above devices don't appear to have > > > > > > their > > > > > > .dts files in the upstream kernel? > > > > > > > > > > > > > > > > Yes, there is a reason. Linux maintainers treat submitters as > > > > > existential enemies or as dirt at least. I was trying to work with > > > > > linux but I have no desire to spend any time to upstream endeavoru or > > > > > lg_x3. > > > > > > > > The usual policy for acceptance into U-Boot is to have upstream review > > > > in the kernel first. > > > > > > > > > > May you point to a policy which clearly and explicitly states this as > > > a mandatory condition? > > > > There have been a number of devices rejected in the past until their > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:, > > to clarify the exact policy. > > Well, here is where it's tricky. I brought this up for one of the > Broadcom MIPS platforms a week or two back, and Linus Walleij's point > (and I'm paraphrasing) is there's not really an upstream for it to go. > > What we cannot have is device tree bindings[1] that aren't upstream or > worse yet conflict with the official bindings. > > So the general way to resolve that is have device tree file be drop-in > from the linux kernel, and what additions we must have be done via > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in > sync with the kernel than other SoCs are. > > Now, upstream being actively hostile to dts files, especially for older > platforms? That's unfortunate. So long as we aren't violating the rules > about bindings, the intention is that we don't have device trees that > are either (a) massively out of sync with the kernel[2] or (b) kept > intentionally mismatched from the kernel. I don't believe I've seen upstream Tegra maintainers being actively hostile towards updates for older devices, I know they have certainly defocused them, but I'm not sure that's what I'd consider hostile. > [1]: There are both examples like binman that Simon is working on at > least but this is more exception than intentional rule. > [2]: Per our other conversions, I know the tegra ones are in this > unfortunate state in general
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
On Mon, Nov 06, 2023 at 02:11:16PM +, Peter Robinson wrote: > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel wrote: > > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson пише: > > > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel > > > wrote: > > > > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson пише: > > > > > > > > > > Hi Svyatoslav, > > > > > > > > > > > Since the proposed PMIC patches have been accepted, I see the need > > > > > > to convert boards which I maintain to use DM drivers instead of > > > > > > board hacks. > > > > > > > > > > > > Svyatoslav Ryhel (5): > > > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > > > > > board: endeavoru: convert HTC One X to use DM PMIC > > > > > > > > > > Is there a reason why the two above devices don't appear to have their > > > > > .dts files in the upstream kernel? > > > > > > > > > > > > > Yes, there is a reason. Linux maintainers treat submitters as > > > > existential enemies or as dirt at least. I was trying to work with > > > > linux but I have no desire to spend any time to upstream endeavoru or > > > > lg_x3. > > > > > > The usual policy for acceptance into U-Boot is to have upstream review > > > in the kernel first. > > > > > > > May you point to a policy which clearly and explicitly states this as > > a mandatory condition? > > There have been a number of devices rejected in the past until their > DT are upstream but I'll leave Tom, who I've explicitly added on cc:, > to clarify the exact policy. Well, here is where it's tricky. I brought this up for one of the Broadcom MIPS platforms a week or two back, and Linus Walleij's point (and I'm paraphrasing) is there's not really an upstream for it to go. What we cannot have is device tree bindings[1] that aren't upstream or worse yet conflict with the official bindings. So the general way to resolve that is have device tree file be drop-in from the linux kernel, and what additions we must have be done via -u-boot.dtsi files. And in turn, some SoCs are better about keeping in sync with the kernel than other SoCs are. Now, upstream being actively hostile to dts files, especially for older platforms? That's unfortunate. So long as we aren't violating the rules about bindings, the intention is that we don't have device trees that are either (a) massively out of sync with the kernel[2] or (b) kept intentionally mismatched from the kernel. -- Tom [1]: There are both examples like binman that Simon is working on at least but this is more exception than intentional rule. [2]: Per our other conversions, I know the tegra ones are in this unfortunate state in general signature.asc Description: PGP signature
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel wrote: > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson пише: > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel wrote: > > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson пише: > > > > > > > > Hi Svyatoslav, > > > > > > > > > Since the proposed PMIC patches have been accepted, I see the need > > > > > to convert boards which I maintain to use DM drivers instead of board > > > > > hacks. > > > > > > > > > > Svyatoslav Ryhel (5): > > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > > > > board: endeavoru: convert HTC One X to use DM PMIC > > > > > > > > Is there a reason why the two above devices don't appear to have their > > > > .dts files in the upstream kernel? > > > > > > > > > > Yes, there is a reason. Linux maintainers treat submitters as > > > existential enemies or as dirt at least. I was trying to work with > > > linux but I have no desire to spend any time to upstream endeavoru or > > > lg_x3. > > > > The usual policy for acceptance into U-Boot is to have upstream review > > in the kernel first. > > > > May you point to a policy which clearly and explicitly states this as > a mandatory condition? There have been a number of devices rejected in the past until their DT are upstream but I'll leave Tom, who I've explicitly added on cc:, to clarify the exact policy. > > > > > board: transformer-t30: convert ASUS Transformers to use DM PMIC > > > > > board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC > > > > > ARM: dts: tegra30: enable USB PHY node on some devices > > > > > > > > > > arch/arm/dts/tegra30-asus-grouper-common.dtsi | 7 + > > > > > .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 1 + > > > > > .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 1 + > > > > > .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 1 + > > > > > arch/arm/dts/tegra30-asus-p1801-t.dts | 17 ++ > > > > > arch/arm/dts/tegra30-asus-tf600t.dts | 15 ++ > > > > > arch/arm/dts/tegra30-asus-transformer.dtsi| 9 + > > > > > arch/arm/dts/tegra30-htc-endeavoru.dts| 8 + > > > > > arch/arm/dts/tegra30-lg-x3.dtsi | 9 + > > > > > board/asus/grouper/Kconfig| 8 - > > > > > board/asus/grouper/Makefile | 4 +- > > > > > .../asus/grouper/configs/grouper_E1565.config | 6 +- > > > > > .../asus/grouper/configs/grouper_PM269.config | 6 +- > > > > > board/asus/grouper/configs/tilapia.config | 6 +- > > > > > board/asus/grouper/grouper-spl-max.c | 2 +- > > > > > board/asus/grouper/grouper-spl-ti.c | 2 +- > > > > > board/asus/grouper/grouper.c | 154 > > > > > +- > > > > > board/asus/transformer-t30/Kconfig| 10 -- > > > > > .../transformer-t30/configs/tf600t.config | 2 +- > > > > > .../transformer-t30/transformer-t30-spl.c | 2 +- > > > > > board/asus/transformer-t30/transformer-t30.c | 121 +- > > > > > board/htc/endeavoru/endeavoru-spl.c | 2 +- > > > > > board/htc/endeavoru/endeavoru.c | 72 +--- > > > > > board/lg/x3-t30/x3-t30-spl.c | 2 +- > > > > > board/lg/x3-t30/x3-t30.c | 97 +-- > > > > > configs/endeavoru_defconfig | 4 + > > > > > configs/grouper_common_defconfig | 1 + > > > > > configs/transformer_t30_defconfig | 5 + > > > > > configs/x3_t30_defconfig | 4 + > > > > > 29 files changed, 128 insertions(+), 450 deletions(-) > > > > > > > > > > -- > > > > > 2.40.1 > > > > >
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
пн, 6 лист. 2023 р. о 15:13 Peter Robinson пише: > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel wrote: > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson пише: > > > > > > Hi Svyatoslav, > > > > > > > Since the proposed PMIC patches have been accepted, I see the need > > > > to convert boards which I maintain to use DM drivers instead of board > > > > hacks. > > > > > > > > Svyatoslav Ryhel (5): > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > > > board: endeavoru: convert HTC One X to use DM PMIC > > > > > > Is there a reason why the two above devices don't appear to have their > > > .dts files in the upstream kernel? > > > > > > > Yes, there is a reason. Linux maintainers treat submitters as > > existential enemies or as dirt at least. I was trying to work with > > linux but I have no desire to spend any time to upstream endeavoru or > > lg_x3. > > The usual policy for acceptance into U-Boot is to have upstream review > in the kernel first. > May you point to a policy which clearly and explicitly states this as a mandatory condition? > > > > board: transformer-t30: convert ASUS Transformers to use DM PMIC > > > > board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC > > > > ARM: dts: tegra30: enable USB PHY node on some devices > > > > > > > > arch/arm/dts/tegra30-asus-grouper-common.dtsi | 7 + > > > > .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 1 + > > > > .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 1 + > > > > .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 1 + > > > > arch/arm/dts/tegra30-asus-p1801-t.dts | 17 ++ > > > > arch/arm/dts/tegra30-asus-tf600t.dts | 15 ++ > > > > arch/arm/dts/tegra30-asus-transformer.dtsi| 9 + > > > > arch/arm/dts/tegra30-htc-endeavoru.dts| 8 + > > > > arch/arm/dts/tegra30-lg-x3.dtsi | 9 + > > > > board/asus/grouper/Kconfig| 8 - > > > > board/asus/grouper/Makefile | 4 +- > > > > .../asus/grouper/configs/grouper_E1565.config | 6 +- > > > > .../asus/grouper/configs/grouper_PM269.config | 6 +- > > > > board/asus/grouper/configs/tilapia.config | 6 +- > > > > board/asus/grouper/grouper-spl-max.c | 2 +- > > > > board/asus/grouper/grouper-spl-ti.c | 2 +- > > > > board/asus/grouper/grouper.c | 154 +- > > > > board/asus/transformer-t30/Kconfig| 10 -- > > > > .../transformer-t30/configs/tf600t.config | 2 +- > > > > .../transformer-t30/transformer-t30-spl.c | 2 +- > > > > board/asus/transformer-t30/transformer-t30.c | 121 +- > > > > board/htc/endeavoru/endeavoru-spl.c | 2 +- > > > > board/htc/endeavoru/endeavoru.c | 72 +--- > > > > board/lg/x3-t30/x3-t30-spl.c | 2 +- > > > > board/lg/x3-t30/x3-t30.c | 97 +-- > > > > configs/endeavoru_defconfig | 4 + > > > > configs/grouper_common_defconfig | 1 + > > > > configs/transformer_t30_defconfig | 5 + > > > > configs/x3_t30_defconfig | 4 + > > > > 29 files changed, 128 insertions(+), 450 deletions(-) > > > > > > > > -- > > > > 2.40.1 > > > >
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel wrote: > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson пише: > > > > Hi Svyatoslav, > > > > > Since the proposed PMIC patches have been accepted, I see the need > > > to convert boards which I maintain to use DM drivers instead of board > > > hacks. > > > > > > Svyatoslav Ryhel (5): > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > > board: endeavoru: convert HTC One X to use DM PMIC > > > > Is there a reason why the two above devices don't appear to have their > > .dts files in the upstream kernel? > > > > Yes, there is a reason. Linux maintainers treat submitters as > existential enemies or as dirt at least. I was trying to work with > linux but I have no desire to spend any time to upstream endeavoru or > lg_x3. The usual policy for acceptance into U-Boot is to have upstream review in the kernel first. > > > board: transformer-t30: convert ASUS Transformers to use DM PMIC > > > board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC > > > ARM: dts: tegra30: enable USB PHY node on some devices > > > > > > arch/arm/dts/tegra30-asus-grouper-common.dtsi | 7 + > > > .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 1 + > > > .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 1 + > > > .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 1 + > > > arch/arm/dts/tegra30-asus-p1801-t.dts | 17 ++ > > > arch/arm/dts/tegra30-asus-tf600t.dts | 15 ++ > > > arch/arm/dts/tegra30-asus-transformer.dtsi| 9 + > > > arch/arm/dts/tegra30-htc-endeavoru.dts| 8 + > > > arch/arm/dts/tegra30-lg-x3.dtsi | 9 + > > > board/asus/grouper/Kconfig| 8 - > > > board/asus/grouper/Makefile | 4 +- > > > .../asus/grouper/configs/grouper_E1565.config | 6 +- > > > .../asus/grouper/configs/grouper_PM269.config | 6 +- > > > board/asus/grouper/configs/tilapia.config | 6 +- > > > board/asus/grouper/grouper-spl-max.c | 2 +- > > > board/asus/grouper/grouper-spl-ti.c | 2 +- > > > board/asus/grouper/grouper.c | 154 +- > > > board/asus/transformer-t30/Kconfig| 10 -- > > > .../transformer-t30/configs/tf600t.config | 2 +- > > > .../transformer-t30/transformer-t30-spl.c | 2 +- > > > board/asus/transformer-t30/transformer-t30.c | 121 +- > > > board/htc/endeavoru/endeavoru-spl.c | 2 +- > > > board/htc/endeavoru/endeavoru.c | 72 +--- > > > board/lg/x3-t30/x3-t30-spl.c | 2 +- > > > board/lg/x3-t30/x3-t30.c | 97 +-- > > > configs/endeavoru_defconfig | 4 + > > > configs/grouper_common_defconfig | 1 + > > > configs/transformer_t30_defconfig | 5 + > > > configs/x3_t30_defconfig | 4 + > > > 29 files changed, 128 insertions(+), 450 deletions(-) > > > > > > -- > > > 2.40.1 > > >
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
пн, 6 лист. 2023 р. о 13:46 Peter Robinson пише: > > Hi Svyatoslav, > > > Since the proposed PMIC patches have been accepted, I see the need > > to convert boards which I maintain to use DM drivers instead of board hacks. > > > > Svyatoslav Ryhel (5): > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > board: endeavoru: convert HTC One X to use DM PMIC > > Is there a reason why the two above devices don't appear to have their > .dts files in the upstream kernel? > Yes, there is a reason. Linux maintainers treat submitters as existential enemies or as dirt at least. I was trying to work with linux but I have no desire to spend any time to upstream endeavoru or lg_x3. > > board: transformer-t30: convert ASUS Transformers to use DM PMIC > > board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC > > ARM: dts: tegra30: enable USB PHY node on some devices > > > > arch/arm/dts/tegra30-asus-grouper-common.dtsi | 7 + > > .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 1 + > > .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 1 + > > .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 1 + > > arch/arm/dts/tegra30-asus-p1801-t.dts | 17 ++ > > arch/arm/dts/tegra30-asus-tf600t.dts | 15 ++ > > arch/arm/dts/tegra30-asus-transformer.dtsi| 9 + > > arch/arm/dts/tegra30-htc-endeavoru.dts| 8 + > > arch/arm/dts/tegra30-lg-x3.dtsi | 9 + > > board/asus/grouper/Kconfig| 8 - > > board/asus/grouper/Makefile | 4 +- > > .../asus/grouper/configs/grouper_E1565.config | 6 +- > > .../asus/grouper/configs/grouper_PM269.config | 6 +- > > board/asus/grouper/configs/tilapia.config | 6 +- > > board/asus/grouper/grouper-spl-max.c | 2 +- > > board/asus/grouper/grouper-spl-ti.c | 2 +- > > board/asus/grouper/grouper.c | 154 +- > > board/asus/transformer-t30/Kconfig| 10 -- > > .../transformer-t30/configs/tf600t.config | 2 +- > > .../transformer-t30/transformer-t30-spl.c | 2 +- > > board/asus/transformer-t30/transformer-t30.c | 121 +- > > board/htc/endeavoru/endeavoru-spl.c | 2 +- > > board/htc/endeavoru/endeavoru.c | 72 +--- > > board/lg/x3-t30/x3-t30-spl.c | 2 +- > > board/lg/x3-t30/x3-t30.c | 97 +-- > > configs/endeavoru_defconfig | 4 + > > configs/grouper_common_defconfig | 1 + > > configs/transformer_t30_defconfig | 5 + > > configs/x3_t30_defconfig | 4 + > > 29 files changed, 128 insertions(+), 450 deletions(-) > > > > -- > > 2.40.1 > >
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
Hi Svyatoslav, > Since the proposed PMIC patches have been accepted, I see the need > to convert boards which I maintain to use DM drivers instead of board hacks. > > Svyatoslav Ryhel (5): > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > board: endeavoru: convert HTC One X to use DM PMIC Is there a reason why the two above devices don't appear to have their .dts files in the upstream kernel? > board: transformer-t30: convert ASUS Transformers to use DM PMIC > board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC > ARM: dts: tegra30: enable USB PHY node on some devices > > arch/arm/dts/tegra30-asus-grouper-common.dtsi | 7 + > .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 1 + > .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 1 + > .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 1 + > arch/arm/dts/tegra30-asus-p1801-t.dts | 17 ++ > arch/arm/dts/tegra30-asus-tf600t.dts | 15 ++ > arch/arm/dts/tegra30-asus-transformer.dtsi| 9 + > arch/arm/dts/tegra30-htc-endeavoru.dts| 8 + > arch/arm/dts/tegra30-lg-x3.dtsi | 9 + > board/asus/grouper/Kconfig| 8 - > board/asus/grouper/Makefile | 4 +- > .../asus/grouper/configs/grouper_E1565.config | 6 +- > .../asus/grouper/configs/grouper_PM269.config | 6 +- > board/asus/grouper/configs/tilapia.config | 6 +- > board/asus/grouper/grouper-spl-max.c | 2 +- > board/asus/grouper/grouper-spl-ti.c | 2 +- > board/asus/grouper/grouper.c | 154 +- > board/asus/transformer-t30/Kconfig| 10 -- > .../transformer-t30/configs/tf600t.config | 2 +- > .../transformer-t30/transformer-t30-spl.c | 2 +- > board/asus/transformer-t30/transformer-t30.c | 121 +- > board/htc/endeavoru/endeavoru-spl.c | 2 +- > board/htc/endeavoru/endeavoru.c | 72 +--- > board/lg/x3-t30/x3-t30-spl.c | 2 +- > board/lg/x3-t30/x3-t30.c | 97 +-- > configs/endeavoru_defconfig | 4 + > configs/grouper_common_defconfig | 1 + > configs/transformer_t30_defconfig | 5 + > configs/x3_t30_defconfig | 4 + > 29 files changed, 128 insertions(+), 450 deletions(-) > > -- > 2.40.1 >
[PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
Since the proposed PMIC patches have been accepted, I see the need to convert boards which I maintain to use DM drivers instead of board hacks. Svyatoslav Ryhel (5): board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC board: endeavoru: convert HTC One X to use DM PMIC board: transformer-t30: convert ASUS Transformers to use DM PMIC board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC ARM: dts: tegra30: enable USB PHY node on some devices arch/arm/dts/tegra30-asus-grouper-common.dtsi | 7 + .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 1 + .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 1 + .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 1 + arch/arm/dts/tegra30-asus-p1801-t.dts | 17 ++ arch/arm/dts/tegra30-asus-tf600t.dts | 15 ++ arch/arm/dts/tegra30-asus-transformer.dtsi| 9 + arch/arm/dts/tegra30-htc-endeavoru.dts| 8 + arch/arm/dts/tegra30-lg-x3.dtsi | 9 + board/asus/grouper/Kconfig| 8 - board/asus/grouper/Makefile | 4 +- .../asus/grouper/configs/grouper_E1565.config | 6 +- .../asus/grouper/configs/grouper_PM269.config | 6 +- board/asus/grouper/configs/tilapia.config | 6 +- board/asus/grouper/grouper-spl-max.c | 2 +- board/asus/grouper/grouper-spl-ti.c | 2 +- board/asus/grouper/grouper.c | 154 +- board/asus/transformer-t30/Kconfig| 10 -- .../transformer-t30/configs/tf600t.config | 2 +- .../transformer-t30/transformer-t30-spl.c | 2 +- board/asus/transformer-t30/transformer-t30.c | 121 +- board/htc/endeavoru/endeavoru-spl.c | 2 +- board/htc/endeavoru/endeavoru.c | 72 +--- board/lg/x3-t30/x3-t30-spl.c | 2 +- board/lg/x3-t30/x3-t30.c | 97 +-- configs/endeavoru_defconfig | 4 + configs/grouper_common_defconfig | 1 + configs/transformer_t30_defconfig | 5 + configs/x3_t30_defconfig | 4 + 29 files changed, 128 insertions(+), 450 deletions(-) -- 2.40.1
