Re: [PATCH v2 05/11] Documentation: DT: bindings: mfd: add A33 GPADC binding
Hi,
On Sat, Mar 11, 2017 at 03:07:55PM +0100, Quentin Schulz wrote:
> Hi Icenowy,
>
> On 10/03/2017 20:25, Icenowy Zheng wrote:
> >
> >
> > 10.03.2017, 18:56, "Quentin Schulz" <quentin.sch...@free-electrons.com>:
> >> This patch adds documentation for the A33 GPADC binding.
> >>
> >> Signed-off-by: Quentin Schulz <quentin.sch...@free-electrons.com>
> >> ---
> >>
> >> added in v2
> >>
> >> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 59 ++
> >> 1 file changed, 59 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >> b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >> new file mode 100644
> >> index 000..17242c8
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >> @@ -0,0 +1,59 @@
> >> +Allwinner SoCs' GPADC Device Tree bindings
> >> +--
> >> +The Allwinner SoCs all have an ADC that can also act as a thermal sensor
> >> +and sometimes as a touchscreen controller.
> >> +
> >> +Required properties:
> >> + - compatible: "sun8i-a33-gpadc-iio",
> >> + - reg: mmio address range of the chip,
> >> + - #thermal-sensor-cells: shall be 0,
> >> + - #io-channel-cells: shall be 0,
> >> +
> >> +Example:
> >> + rtp: rtp@01c25000 {
> >
> > I think we'd better call it ths.
>
> To match the datasheet, I agree.
I agree too.
> > And can you make thermal-sensor-cells become 1?
> >
> > Maxime Ripard wants to base H3/H5/A64 thermal driver on this patchset, and
> > for H5/A64 there's 2/3 thermal sensors.
>
> Yes, that'll require a specific DT node for those thermal sensors. Then
> since we would update the possible compatibles in the documentation
> anyway, that would be a good idea to update to say that
> thermal-sensor-cells could be different from 0 too.
>
> That was my mindset to set thermal-sensor-cells to 0, since we only
> support SoC which has only one thermal sensor at the moment.
And I agree here as well.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH v2 05/11] Documentation: DT: bindings: mfd: add A33 GPADC binding
Hi,
On Sat, Mar 11, 2017 at 03:07:55PM +0100, Quentin Schulz wrote:
> Hi Icenowy,
>
> On 10/03/2017 20:25, Icenowy Zheng wrote:
> >
> >
> > 10.03.2017, 18:56, "Quentin Schulz" :
> >> This patch adds documentation for the A33 GPADC binding.
> >>
> >> Signed-off-by: Quentin Schulz
> >> ---
> >>
> >> added in v2
> >>
> >> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 59 ++
> >> 1 file changed, 59 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >> b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >> new file mode 100644
> >> index 000..17242c8
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> >> @@ -0,0 +1,59 @@
> >> +Allwinner SoCs' GPADC Device Tree bindings
> >> +--
> >> +The Allwinner SoCs all have an ADC that can also act as a thermal sensor
> >> +and sometimes as a touchscreen controller.
> >> +
> >> +Required properties:
> >> + - compatible: "sun8i-a33-gpadc-iio",
> >> + - reg: mmio address range of the chip,
> >> + - #thermal-sensor-cells: shall be 0,
> >> + - #io-channel-cells: shall be 0,
> >> +
> >> +Example:
> >> + rtp: rtp@01c25000 {
> >
> > I think we'd better call it ths.
>
> To match the datasheet, I agree.
I agree too.
> > And can you make thermal-sensor-cells become 1?
> >
> > Maxime Ripard wants to base H3/H5/A64 thermal driver on this patchset, and
> > for H5/A64 there's 2/3 thermal sensors.
>
> Yes, that'll require a specific DT node for those thermal sensors. Then
> since we would update the possible compatibles in the documentation
> anyway, that would be a good idea to update to say that
> thermal-sensor-cells could be different from 0 too.
>
> That was my mindset to set thermal-sensor-cells to 0, since we only
> support SoC which has only one thermal sensor at the moment.
And I agree here as well.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [linux-sunxi] Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs
On Thu, Mar 02, 2017 at 11:13:53PM +0800, Icenowy Zheng wrote: > > > 02.03.2017, 22:09, "Maxime Ripard" <maxime.rip...@free-electrons.com>: > > On Wed, Mar 01, 2017 at 08:22:13PM +0800, Icenowy Zheng wrote: > >> > I'm a bit worried by that to be honest. You claim to support the A31, > >> > yet jugdging by the current state of that code you never actually > >> > tested it on that SoC. > >> > > >> > What makes you say that the PRCM clocks are the same for the H3 and > >> > A64? We have to be sure, otherwise we might not be able to get the DT > >> > binding right from the very beginning, and we might not be able to fix > >> > it later. > >> > >> In fact, if we worry about this, we shouldn't make r-ccu, as > >> dedicated clocks are more easy to fix. > >> > >> For newer SoCs' PRCM, we never have enough documents, and Allwinner > >> have said that they cannot provide it. (I asked them for this.) > >> > >> The best solution is to implement mature enough dedicated clocks > >> before we convert to ccu. > > > > What do you mean by dedicated clocks? > > The legacy form of clocks. Which itself creates another form of issues. What happens if we get something wrong on those clocks (as it is likely to happen)? We potentially can't fix it at all, that's what happens. And that's leaving aside the DT and clocks maintainers regular complaints that we should get away from those. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [linux-sunxi] Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs
On Thu, Mar 02, 2017 at 11:13:53PM +0800, Icenowy Zheng wrote: > > > 02.03.2017, 22:09, "Maxime Ripard" : > > On Wed, Mar 01, 2017 at 08:22:13PM +0800, Icenowy Zheng wrote: > >> > I'm a bit worried by that to be honest. You claim to support the A31, > >> > yet jugdging by the current state of that code you never actually > >> > tested it on that SoC. > >> > > >> > What makes you say that the PRCM clocks are the same for the H3 and > >> > A64? We have to be sure, otherwise we might not be able to get the DT > >> > binding right from the very beginning, and we might not be able to fix > >> > it later. > >> > >> In fact, if we worry about this, we shouldn't make r-ccu, as > >> dedicated clocks are more easy to fix. > >> > >> For newer SoCs' PRCM, we never have enough documents, and Allwinner > >> have said that they cannot provide it. (I asked them for this.) > >> > >> The best solution is to implement mature enough dedicated clocks > >> before we convert to ccu. > > > > What do you mean by dedicated clocks? > > The legacy form of clocks. Which itself creates another form of issues. What happens if we get something wrong on those clocks (as it is likely to happen)? We potentially can't fix it at all, that's what happens. And that's leaving aside the DT and clocks maintainers regular complaints that we should get away from those. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
FW:
GOOGLE EUROPA INTERLOTTO / EUROMILLINEN FREE-LOTTO BONUS-PROGRAMM BÜRO: PLAZA EMILIO JIM NEZ MILLAS 3352, MADRID, SPANIEN. Aufmerksamkeit: Dies soll Ihnen mitteilen, dass Sie 1,450,000.00Euro von Google Inc-Free-Lotto, 2016 saction gewonnen haben und keine öffentliche Verlosung durchgeführt wurde und kein Ticket verkauft wurde. Die Auslosung erfolgte über das Internet unter allen E-Mail-Dienstleistern auf der ganzen Welt mit elektronischen Mitteln, und die Auswahl erfolgte zufällig. Sie wurden für diese Promo-Award gewählt, Online-E-Mail-Abstimmung wurde ohne Ihr Wissen durchgeführt, wurde es offiziell veröffentlicht heute. Sie haben die Anforderungen, gesetzlichen Verpflichtungen, Prüfungen und unseren zufriedenstellenden Berichtstest für alle unsere Online-Gewinner erfolgreich bestanden. Eine gewinnende Kreditkarte (MASTER CARD) im Wert von 1.450.000,00 Euro wird in Ihrem Namen von Google Promotion Award Team ausgestellt werden. Klicken Sie auf die Website-Link, um die Fotoseite unserer letzten Google-Free-Lotto letzten glücklichen Gewinner zu sehen. http://www.freelotto.com/winners.asp *** *** Füllen Sie das folgende Formular aus: (1) Ihr vollständiger Name . (2) Kontaktadresse (3) Mobile / Tell (4) Staatsangehörigkeit / Land (5) Beruf (6) Alter ... (8) Haben Sie jemals eine Online-Lotterie gewonnen? Aufrechtzuerhalten. *** *** Wenden Sie sich an die benannte Bevollmächtigte Herr Mark Reeves und Frau .Gisela Hanne, und co per E-Mail sofort innerhalb der nächsten 24 Stunden nach Erhalt dieser Notifizierung des Preises. *** *** Head Winning Claims Abt. Offizielle E-Mail: customer.servic...@yahoo.es Kontakt E-Mail: kund.zen...@yahoo.de Tel: +1 927-477-5302 *** *** Herzlichen Glückwunsch noch einmal von den Mitarbeitern und Mitgliedern der Google Interactive Lottery Board Commission. Schild, Herr. Geschäftsführer (C.E.O). Hauptsitz Google Inc. 1600 Amphitheatre Parkway entfernt Mountain View, CA 94043 Gästebewertungen *** Copyright © 1999-2016 PlasmaNet Inc. Alle Rechte vorbehalten. Klicken Sie hier http://www.freelotto.com/winners.asp um die letzten Google-Free-Lotto Glücksgewinner zu sehen.
FW:
GOOGLE EUROPA INTERLOTTO / EUROMILLINEN FREE-LOTTO BONUS-PROGRAMM BÜRO: PLAZA EMILIO JIM NEZ MILLAS 3352, MADRID, SPANIEN. Aufmerksamkeit: Dies soll Ihnen mitteilen, dass Sie 1,450,000.00Euro von Google Inc-Free-Lotto, 2016 saction gewonnen haben und keine öffentliche Verlosung durchgeführt wurde und kein Ticket verkauft wurde. Die Auslosung erfolgte über das Internet unter allen E-Mail-Dienstleistern auf der ganzen Welt mit elektronischen Mitteln, und die Auswahl erfolgte zufällig. Sie wurden für diese Promo-Award gewählt, Online-E-Mail-Abstimmung wurde ohne Ihr Wissen durchgeführt, wurde es offiziell veröffentlicht heute. Sie haben die Anforderungen, gesetzlichen Verpflichtungen, Prüfungen und unseren zufriedenstellenden Berichtstest für alle unsere Online-Gewinner erfolgreich bestanden. Eine gewinnende Kreditkarte (MASTER CARD) im Wert von 1.450.000,00 Euro wird in Ihrem Namen von Google Promotion Award Team ausgestellt werden. Klicken Sie auf die Website-Link, um die Fotoseite unserer letzten Google-Free-Lotto letzten glücklichen Gewinner zu sehen. http://www.freelotto.com/winners.asp *** *** Füllen Sie das folgende Formular aus: (1) Ihr vollständiger Name . (2) Kontaktadresse (3) Mobile / Tell (4) Staatsangehörigkeit / Land (5) Beruf (6) Alter ... (8) Haben Sie jemals eine Online-Lotterie gewonnen? Aufrechtzuerhalten. *** *** Wenden Sie sich an die benannte Bevollmächtigte Herr Mark Reeves und Frau .Gisela Hanne, und co per E-Mail sofort innerhalb der nächsten 24 Stunden nach Erhalt dieser Notifizierung des Preises. *** *** Head Winning Claims Abt. Offizielle E-Mail: customer.servic...@yahoo.es Kontakt E-Mail: kund.zen...@yahoo.de Tel: +1 927-477-5302 *** *** Herzlichen Glückwunsch noch einmal von den Mitarbeitern und Mitgliedern der Google Interactive Lottery Board Commission. Schild, Herr. Geschäftsführer (C.E.O). Hauptsitz Google Inc. 1600 Amphitheatre Parkway entfernt Mountain View, CA 94043 Gästebewertungen *** Copyright © 1999-2016 PlasmaNet Inc. Alle Rechte vorbehalten. Klicken Sie hier http://www.freelotto.com/winners.asp um die letzten Google-Free-Lotto Glücksgewinner zu sehen.
Re: [PATCH 2/2] ASoC: sunxi: compatibility for sun6i to SPDIF
On Sat, Jul 30, 2016 at 10:52:45PM +0800, Icenowy Zheng wrote:
> > + if (of_device_is_compatible(pdev->dev.of_node,
> > + "allwinner,sun6i-a31-spdif")) {
> > + host->rst = devm_reset_control_get_optional(>dev, NULL);
> > + if (IS_ERR(host->rst) && PTR_ERR(host->rst) == -EPROBE_DEFER) {
> > + ret = -EPROBE_DEFER;
> > + dev_err(>dev, "Failed to get reset: %d\n", ret);
> > + goto err_disable_apb_clk;
> > + }
> > + if (!IS_ERR(host->rst))
> > + reset_control_deassert(host->rst);
> > + }
> > +
> I think you do not need the compatible.
> You can just detect whether the reset is present.
That would weaken the error check. If we're running on the A31 and are
missing our reset property, it would go unnoticed.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH 2/2] ASoC: sunxi: compatibility for sun6i to SPDIF
On Sat, Jul 30, 2016 at 10:52:45PM +0800, Icenowy Zheng wrote:
> > + if (of_device_is_compatible(pdev->dev.of_node,
> > + "allwinner,sun6i-a31-spdif")) {
> > + host->rst = devm_reset_control_get_optional(>dev, NULL);
> > + if (IS_ERR(host->rst) && PTR_ERR(host->rst) == -EPROBE_DEFER) {
> > + ret = -EPROBE_DEFER;
> > + dev_err(>dev, "Failed to get reset: %d\n", ret);
> > + goto err_disable_apb_clk;
> > + }
> > + if (!IS_ERR(host->rst))
> > + reset_control_deassert(host->rst);
> > + }
> > +
> I think you do not need the compatible.
> You can just detect whether the reset is present.
That would weaken the error check. If we're running on the A31 and are
missing our reset property, it would go unnoticed.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver
On Tue, Jul 05, 2016 at 04:33:31PM +0800, Icenowy Zheng wrote: > > > 05.07.2016, 13:26, "Michael Haas" <michael.h...@mailbox.org>: > > Hi, > > > > nice work! Is this in any way related to Bruno Prémonts driver for the > > axp20x? > > > > I've got a reworked version of that lying around, but it's not quite > > ready for submission. Do you know what pieces are missing in your driver > > for axp20x support - as opposed to axp22x, which is already working? > > Therotically, it can run on axp20x. However, I have currently no > test device. (Still waiting for my C.H.I.P.) So I can only promise > it to run on axp22x. Still, it looks like you just took Bruno's driver, stripped out the axp20x parts and added the one to deal with axp22x. This makes the driver look weird, by being called axp20x, without actually supporting those PMICs, but having some axp22x variables right in the middle. And that's awfully inconsistent. I'd rather have you add the AXP20x driver directly, and then add the needed stuff for the AXP22x. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver
On Tue, Jul 05, 2016 at 04:33:31PM +0800, Icenowy Zheng wrote: > > > 05.07.2016, 13:26, "Michael Haas" : > > Hi, > > > > nice work! Is this in any way related to Bruno Prémonts driver for the > > axp20x? > > > > I've got a reworked version of that lying around, but it's not quite > > ready for submission. Do you know what pieces are missing in your driver > > for axp20x support - as opposed to axp22x, which is already working? > > Therotically, it can run on axp20x. However, I have currently no > test device. (Still waiting for my C.H.I.P.) So I can only promise > it to run on axp22x. Still, it looks like you just took Bruno's driver, stripped out the axp20x parts and added the one to deal with axp22x. This makes the driver look weird, by being called axp20x, without actually supporting those PMICs, but having some axp22x variables right in the middle. And that's awfully inconsistent. I'd rather have you add the AXP20x driver directly, and then add the needed stuff for the AXP22x. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: PGP signature
Re: percpu irq APIs and perf
Hi, On Fri, Dec 11, 2015 at 05:50:22PM +0530, Vineet Gupta wrote: > >> (2) It seems that disabling autoen by default for percpu irq makes sense as > >> evident from drivers/net/ethernet/marvell/mvneta.c where users want to > >> control > >> this. However the comment there is misleading > >> > >> /* Even though the documentation says that request_percpu_irq > >> * doesn't enable the interrupts automatically, it actually > >> * does so on the local CPU. > >> * > >> * Make sure it's disabled. > >> */ > >> > >> Either sme core code is clearing NOAUTOEN or calling enable_precpu_irq() > >> making > >> request_percpu_irq() enable it. > > > > If that's the case, this is a bug. Nobody should enable that interrupt > > until the driver has chosen to do so. > > Perhaps Maxim can shed more light as this seems to be his comment. I don't really have the full context here, but we did this in order to allow RX queue interrupts to be enabled on a particular CPU. The IP was supposed to do that by itself, but we hadn't figure that out at the time. So what we ended up doing is disabling the interrupts by default and then enable it only on the CPU meant to receive the queue interrupts. What we found out doing so was that the per-cpu interrupts were enabled on the cpu calling request_percpu_irq, and so that's why it ended up with that comment. I also fixed the documentation accordingly in a1b7febd725a. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: percpu irq APIs and perf
Hi, On Fri, Dec 11, 2015 at 05:50:22PM +0530, Vineet Gupta wrote: > >> (2) It seems that disabling autoen by default for percpu irq makes sense as > >> evident from drivers/net/ethernet/marvell/mvneta.c where users want to > >> control > >> this. However the comment there is misleading > >> > >> /* Even though the documentation says that request_percpu_irq > >> * doesn't enable the interrupts automatically, it actually > >> * does so on the local CPU. > >> * > >> * Make sure it's disabled. > >> */ > >> > >> Either sme core code is clearing NOAUTOEN or calling enable_precpu_irq() > >> making > >> request_percpu_irq() enable it. > > > > If that's the case, this is a bug. Nobody should enable that interrupt > > until the driver has chosen to do so. > > Perhaps Maxim can shed more light as this seems to be his comment. I don't really have the full context here, but we did this in order to allow RX queue interrupts to be enabled on a particular CPU. The IP was supposed to do that by itself, but we hadn't figure that out at the time. So what we ended up doing is disabling the interrupts by default and then enable it only on the CPU meant to receive the queue interrupts. What we found out doing so was that the per-cpu interrupts were enabled on the cpu calling request_percpu_irq, and so that's why it ended up with that comment. I also fixed the documentation accordingly in a1b7febd725a. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Lotto £1,000,000.00
Congratulation we are very happy to inform you of the Free Lotto Award 2015. You should be happy among the five lucky winner your name was selected as a winner of £1,000,000.00 Contact us with your.. Name: Home Address: Occupation: Age: Phone Number: Country Email: freelot...@gmail.com Tell:+44 703 190 8710 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Lotto £1,000,000.00
Congratulation we are very happy to inform you of the Free Lotto Award 2015. You should be happy among the five lucky winner your name was selected as a winner of £1,000,000.00 Contact us with your.. Name: Home Address: Occupation: Age: Phone Number: Country Email: freelot...@gmail.com Tell:+44 703 190 8710 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Serial No.PMSQ021542311,
Confirmation Batch No. GDFS-25-30-29-3-26, Contact Person:Juan De la Silva EMAIL: freelot...@gmail.com TELL:+34-603-307-989 Reference Nr.XKHL-37-14-29-13), Batch No. GDFS-25-30-29-3-26, Serial No.PMSQ021542311, Ticket No.11-48-19-15-14, lucky No.4-19-26-27-30-3-8, You have won( ONE MILLION POUNDS ) in Free lotto online sweepstakes program corporations hold today 21st of October 2015 here In Madrid (SPAIN). This email is been sent to notify you officially about the award and to advise you to contact the processing office immediately for remittance of your Funds. Provide him with these following details with which he will begin the processing of your winnings. 1.NAME: 2.ADDRESS: 3.AGE: 4.PHONE: 5.SEX: 6.MARITAL STATUS: 7.OCCUPATION: 8.COUNTRY: 9.NATIONALITY: Sincerely Daniel Fernández Juanes Lottery Co ordinator -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Serial No.PMSQ021542311,
Confirmation Batch No. GDFS-25-30-29-3-26, Contact Person:Juan De la Silva EMAIL: freelot...@gmail.com TELL:+34-603-307-989 Reference Nr.XKHL-37-14-29-13), Batch No. GDFS-25-30-29-3-26, Serial No.PMSQ021542311, Ticket No.11-48-19-15-14, lucky No.4-19-26-27-30-3-8, You have won( ONE MILLION POUNDS ) in Free lotto online sweepstakes program corporations hold today 21st of October 2015 here In Madrid (SPAIN). This email is been sent to notify you officially about the award and to advise you to contact the processing office immediately for remittance of your Funds. Provide him with these following details with which he will begin the processing of your winnings. 1.NAME: 2.ADDRESS: 3.AGE: 4.PHONE: 5.SEX: 6.MARITAL STATUS: 7.OCCUPATION: 8.COUNTRY: 9.NATIONALITY: Sincerely Daniel Fernández Juanes Lottery Co ordinator -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] axs_nand - add driver for NAND controller used on Synopsys AXS dev boards
On Apr 11, Alexey Brodkin wrote:
> Hi Ezequiel,
>
> On Mon, 2014-04-07 at 10:13 +0400, Alexey Brodkin wrote:
> > Hi Ezequiel,
> >
> > On Fri, 2014-04-04 at 11:09 -0300, Ezequiel Garcia wrote:
> > > On Apr 04, Alexey Brodkin wrote:
> > > > Signed-off-by: Alexey Brodkin
> > > >
> > >
> > > Maybe it would be nice adding some driver description here, so the commit
> > > log actually says something useful about the commit.
> >
> > Well, I thought about it but frankly I'm not sure if there's anything
> > else to add to commit title "driver for NAND controller used on Synopsys
> > AXS dev boards".
> >
> > Do you think more info may make sense?
> >
> > > > +/**
> > > > + * axs_flag_wait_and_reset - Waits until requested flag in INT_STATUS
> > > > register
> > > > + * is set by HW and resets it by writing "1" in
> > > > INT_CLR_STATUS.
> > > > + * @host: Pointer to private data structure.
> > > > + * @flag: Bit/flag offset in INT_STATUS register
> > > > + */
> > > > +static void axs_flag_wait_and_reset(struct axs_nand_host *host, int
> > > > flag)
> > > > +{
> > > > + unsigned int i;
> > > > +
> > > > + for (i = 0; i < AXS_FLAG_WAIT_DELAY * 100; i++) {
> > > > + unsigned int status = reg_get(host, INT_STATUS);
> > > > +
> > > > + if (status & (1 << flag)) {
> > > > + reg_set(host, INT_CLR_STATUS, 1 << flag);
> > > > + return;
> > > > + }
> > > > +
> > > > + udelay(10);
> > > > + }
> > > > +
> > > > + /*
> > > > +* Since we cannot report this problem any further than
> > > > +* axs_nand_{write|read}_buf() letting user know there's a
> > > > problem.
> > > > +*/
> > > > + dev_err(host->dev, "Waited too long (%d s.) for flag/bit %d\n",
> > > > + AXS_FLAG_WAIT_DELAY, flag);
> > > > +}
> > >
> > > Hm... I'm not sure the above is really true.
> > >
> > > The NAND core uses the replaceable chip->waitfunc callback to check the
> > > status of issued commands. See for instance:
> > >
> > > static int nand_write_oob_std(struct mtd_info *mtd, struct nand_chip
> > > *chip,
> > > int page)
> > > {
> > > int status = 0;
> > > const uint8_t *buf = chip->oob_poi;
> > > int length = mtd->oobsize;
> > >
> > > chip->cmdfunc(mtd, NAND_CMD_SEQIN, mtd->writesize, page);
> > > chip->write_buf(mtd, buf, length);
> > > /* Send command to program the OOB data */
> > > chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
> > >
> > > status = chip->waitfunc(mtd, chip);
> > >
> > > return status & NAND_STATUS_FAIL ? -EIO : 0;
> > > }
> > >
> > > On the other side, if you are clearing the flags in
> > > axs_flag_wait_and_reset()
> > > it might be a bit hard for you to get this right.
> > >
> > > IOW, I'm not saying you *must* do this, but instead suggesting that you
> > > take
> > > a look at waitfunc() and see if it helps report a proper error in the
> > > read/write path.
> >
> > As I may understand from generic implementation of "waitfunc" in
> > "nand_base.c" it checks status of NAND chip itself - which IMHO makes
> > sense. And this is done via NAND_CMD_STATUS command sent to chip through
> > NAND controller.
> >
> > In AXS NAND driver you may see 2 types of wait checks:
> > 1. NAND_ISR_CMDDONE - this flag means that NAND controller has just
> > executed provided command (i.e. set proper signal on control lines of
> > NAND chip etc), but it doesn't mean NAND chip itself has completed
> > command execution. That's why "waitfunc" is not direct replacement here.
> >
> > 2. NAND_ISR_{RX|TX}DMACOMPLETE - this flag indicates completion of DMA
> > transfer to/from NAND chip to RAM. "waitfunc" won't work here as well.
> >
> > I hope this explanation makes sense.
>
> Please treat this message as a gentle reminder.
> I'm wondering if my explanation in the previous email makes any sense or
> I still need to fix stuff.
Well, I was merely suggesting to look into using waitfunc(), so you definitely
don't need to fix anything (at least from my side).
Just as a comment, regarding your explanation above, I think you can override
the waitfunc() and check the NAND_CMD_STATUS, together with the check for your
ISR flags. However, you know more about your hardware than me, so this is
*just* a suggestion.
The driver looks fine broadly speaking. I guess it's up to Brian now to provide
further feedback.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] axs_nand - add driver for NAND controller used on Synopsys AXS dev boards
On Apr 11, Alexey Brodkin wrote:
Hi Ezequiel,
On Mon, 2014-04-07 at 10:13 +0400, Alexey Brodkin wrote:
Hi Ezequiel,
On Fri, 2014-04-04 at 11:09 -0300, Ezequiel Garcia wrote:
On Apr 04, Alexey Brodkin wrote:
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Maybe it would be nice adding some driver description here, so the commit
log actually says something useful about the commit.
Well, I thought about it but frankly I'm not sure if there's anything
else to add to commit title driver for NAND controller used on Synopsys
AXS dev boards.
Do you think more info may make sense?
+/**
+ * axs_flag_wait_and_reset - Waits until requested flag in INT_STATUS
register
+ * is set by HW and resets it by writing 1 in
INT_CLR_STATUS.
+ * @host: Pointer to private data structure.
+ * @flag: Bit/flag offset in INT_STATUS register
+ */
+static void axs_flag_wait_and_reset(struct axs_nand_host *host, int
flag)
+{
+ unsigned int i;
+
+ for (i = 0; i AXS_FLAG_WAIT_DELAY * 100; i++) {
+ unsigned int status = reg_get(host, INT_STATUS);
+
+ if (status (1 flag)) {
+ reg_set(host, INT_CLR_STATUS, 1 flag);
+ return;
+ }
+
+ udelay(10);
+ }
+
+ /*
+* Since we cannot report this problem any further than
+* axs_nand_{write|read}_buf() letting user know there's a
problem.
+*/
+ dev_err(host-dev, Waited too long (%d s.) for flag/bit %d\n,
+ AXS_FLAG_WAIT_DELAY, flag);
+}
Hm... I'm not sure the above is really true.
The NAND core uses the replaceable chip-waitfunc callback to check the
status of issued commands. See for instance:
static int nand_write_oob_std(struct mtd_info *mtd, struct nand_chip
*chip,
int page)
{
int status = 0;
const uint8_t *buf = chip-oob_poi;
int length = mtd-oobsize;
chip-cmdfunc(mtd, NAND_CMD_SEQIN, mtd-writesize, page);
chip-write_buf(mtd, buf, length);
/* Send command to program the OOB data */
chip-cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
status = chip-waitfunc(mtd, chip);
return status NAND_STATUS_FAIL ? -EIO : 0;
}
On the other side, if you are clearing the flags in
axs_flag_wait_and_reset()
it might be a bit hard for you to get this right.
IOW, I'm not saying you *must* do this, but instead suggesting that you
take
a look at waitfunc() and see if it helps report a proper error in the
read/write path.
As I may understand from generic implementation of waitfunc in
nand_base.c it checks status of NAND chip itself - which IMHO makes
sense. And this is done via NAND_CMD_STATUS command sent to chip through
NAND controller.
In AXS NAND driver you may see 2 types of wait checks:
1. NAND_ISR_CMDDONE - this flag means that NAND controller has just
executed provided command (i.e. set proper signal on control lines of
NAND chip etc), but it doesn't mean NAND chip itself has completed
command execution. That's why waitfunc is not direct replacement here.
2. NAND_ISR_{RX|TX}DMACOMPLETE - this flag indicates completion of DMA
transfer to/from NAND chip to RAM. waitfunc won't work here as well.
I hope this explanation makes sense.
Please treat this message as a gentle reminder.
I'm wondering if my explanation in the previous email makes any sense or
I still need to fix stuff.
Well, I was merely suggesting to look into using waitfunc(), so you definitely
don't need to fix anything (at least from my side).
Just as a comment, regarding your explanation above, I think you can override
the waitfunc() and check the NAND_CMD_STATUS, together with the check for your
ISR flags. However, you know more about your hardware than me, so this is
*just* a suggestion.
The driver looks fine broadly speaking. I guess it's up to Brian now to provide
further feedback.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Add smp support for Allwinner A20(sunxi 7i).
Hi, On Mon, Sep 23, 2013 at 10:43:55PM +0800, cinifr wrote: > > In which case this kernel patch needs instead to speak the bootloader > > wakeup protocol instead of speaking to the h/w directly like you've done > > here, right? > > > > Or is it possible for the bootloader to set these things up and then put > > the CPU back to sleep such that it both retains any settings and is > > wakable by this patch? This code contains core resets and power control, > > which makes me suspect not. > > And I think secondary cpus remains setting after h/w boot. > >> > Wouldn't it be better to do all this stuff in the bootloader and > >> either > >> > implement PSCI or have the bootloader do the traditional holding pen > >> and > >> > mbox address thing? > Uboot doesnot support PSCI, it use traditional holding pen for sunxi > platform now. > > >> > > >> I have modified uboot to set cntfrq and cntvoff in all smp cpus,and it > >> works well. I guess kernel should believe all cpu should be all same > >> when kernel boot. Bootloader should do it to ensure that. > > > > Yes, I think all CPUs must be in the same state at boot. > > > > But if you've done all that then what is this patch for? > > > > Do you have links to your u-boot patches? > > > > Ian. > Yes, This is my patch for uboot. > My working uboot code is in https://github.com/linux-sunxi/u-boot-sunxi.git > Note this is only test patch. I have not commit it formally for uboot. Please do so. I'd like very much to avoid ending up in a situation where we would break the mainline kernel for the A20, without any bootloader we can point the users to to fix the issues. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 1/3] Add smp support for Allwinner A20(sunxi 7i).
Hi, On Mon, Sep 23, 2013 at 10:43:55PM +0800, cinifr wrote: In which case this kernel patch needs instead to speak the bootloader wakeup protocol instead of speaking to the h/w directly like you've done here, right? Or is it possible for the bootloader to set these things up and then put the CPU back to sleep such that it both retains any settings and is wakable by this patch? This code contains core resets and power control, which makes me suspect not. And I think secondary cpus remains setting after h/w boot. Wouldn't it be better to do all this stuff in the bootloader and either implement PSCI or have the bootloader do the traditional holding pen and mbox address thing? Uboot doesnot support PSCI, it use traditional holding pen for sunxi platform now. I have modified uboot to set cntfrq and cntvoff in all smp cpus,and it works well. I guess kernel should believe all cpu should be all same when kernel boot. Bootloader should do it to ensure that. Yes, I think all CPUs must be in the same state at boot. But if you've done all that then what is this patch for? Do you have links to your u-boot patches? Ian. Yes, This is my patch for uboot. My working uboot code is in https://github.com/linux-sunxi/u-boot-sunxi.git Note this is only test patch. I have not commit it formally for uboot. Please do so. I'd like very much to avoid ending up in a situation where we would break the mainline kernel for the A20, without any bootloader we can point the users to to fix the issues. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 3/4] Add physical count arch timer support for clocksource in ARMv7.
Hi Marc, Fan, On Fri, Sep 13, 2013 at 10:30:49AM +0100, Marc Zyngier wrote: > On 13/09/13 09:49, cinifr wrote: > > On 13 September 2013 00:39, Marc Zyngier wrote: > > I am wondering what is the principle between kernel and bootload? > > What should be done in bootloader and what should be done in kernel? > > As you said, If kernel boot from hyp, Kernel can set CNTVOFF to zero > > directly, does we add the code to set CNTVOFF in kernel? But, if > > kernel boot from PL1 NS=0, Does kernel need to switch hyp mode to > > set CNTVOFF and return PL1 NS=0 mode? Or,kernel dont care it because > > kernel believe bootloader have set CNTVOFF before? > > In an ideal world, the bootloader should set CNTVOFF to zero. The fact > that the kernel does it too when booted in HYP mode is to preserve > itself from from broken bootloaders. > > CNTVOFF can only be setup from either HYP or Secure Monitor mode with > SCR.NS == 1, so if you run your kernel in secure mode, it is always best > to do it in the bootloader. What would happen exactly if a kernel expects CNTVOFF to be set to 0, and that your bootloader don't set it? From what you're saying, it's will be set by the kernel if it's booted in hypervisor mode, but what if it's not? The ARM documentation says that the CNTVOFF register will hold an undefined value, how would that affect the kernel? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 3/4] Add physical count arch timer support for clocksource in ARMv7.
Hi Marc, Fan, On Fri, Sep 13, 2013 at 10:30:49AM +0100, Marc Zyngier wrote: On 13/09/13 09:49, cinifr wrote: On 13 September 2013 00:39, Marc Zyngier marc.zyng...@arm.com wrote: I am wondering what is the principle between kernel and bootload? What should be done in bootloader and what should be done in kernel? As you said, If kernel boot from hyp, Kernel can set CNTVOFF to zero directly, does we add the code to set CNTVOFF in kernel? But, if kernel boot from PL1 NS=0, Does kernel need to switch hyp mode to set CNTVOFF and return PL1 NS=0 mode? Or,kernel dont care it because kernel believe bootloader have set CNTVOFF before? In an ideal world, the bootloader should set CNTVOFF to zero. The fact that the kernel does it too when booted in HYP mode is to preserve itself from from broken bootloaders. CNTVOFF can only be setup from either HYP or Secure Monitor mode with SCR.NS == 1, so if you run your kernel in secure mode, it is always best to do it in the bootloader. What would happen exactly if a kernel expects CNTVOFF to be set to 0, and that your bootloader don't set it? From what you're saying, it's will be set by the kernel if it's booted in hypervisor mode, but what if it's not? The ARM documentation says that the CNTVOFF register will hold an undefined value, how would that affect the kernel? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH RESEND] video: mxsfb: fix color settings for 18bit data bus and 32bpp
On Wed, Jul 03, 2013 at 10:55:05AM +0200, maxime.rip...@free-electrons.com wrote: > Hi Jean-Christophe, > > On Tue, Jun 18, 2013 at 10:44:17AM +0200, Hector Palacios wrote: > > For a combination of 18bit LCD data bus width and a color > > mode of 32bpp, the driver was setting the color mapping to > > rgb666, which is wrong, as the color in memory realy has an > > rgb888 layout. > > > > This patch also removes the setting of flag CTRL_DF24 that > > makes the driver dimiss the upper 2 bits when handling 32/24bpp > > colors in a diplay with 18bit data bus width. This flag made > > true color images display wrong in such configurations. > > > > Finally, the color mapping rgb666 has also been removed as nobody > > is using it and high level applications like Qt5 cannot work > > with it either. > > > > Reference: https://lkml.org/lkml/2013/5/23/220 > > Signed-off-by: Hector Palacios > > Acked-by: Juergen Beisert > > Acked-by: Maxime Ripard > > I don't see this patch in your for-next branch. > > It would be really great to have it for 3.11 if possible. > > Could you take a look at this patch please? Ping? -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH RESEND] video: mxsfb: fix color settings for 18bit data bus and 32bpp
On Wed, Jul 03, 2013 at 10:55:05AM +0200, maxime.rip...@free-electrons.com wrote: Hi Jean-Christophe, On Tue, Jun 18, 2013 at 10:44:17AM +0200, Hector Palacios wrote: For a combination of 18bit LCD data bus width and a color mode of 32bpp, the driver was setting the color mapping to rgb666, which is wrong, as the color in memory realy has an rgb888 layout. This patch also removes the setting of flag CTRL_DF24 that makes the driver dimiss the upper 2 bits when handling 32/24bpp colors in a diplay with 18bit data bus width. This flag made true color images display wrong in such configurations. Finally, the color mapping rgb666 has also been removed as nobody is using it and high level applications like Qt5 cannot work with it either. Reference: https://lkml.org/lkml/2013/5/23/220 Signed-off-by: Hector Palacios hector.palac...@digi.com Acked-by: Juergen Beisert j...@pengutronix.de Acked-by: Maxime Ripard maxime.rip...@free-electrons.com I don't see this patch in your for-next branch. It would be really great to have it for 3.11 if possible. Could you take a look at this patch please? Ping? -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MXS persistent bits driver
Hi Hector, On Thu, Jul 11, 2013 at 10:56:42AM +0200, Hector Palacios wrote: > On 07/11/2013 10:24 AM, maxime.rip...@free-electrons.com wrote: > >>I haven't seen this is supported upstream. Is anybody working on that? > >>Where would such a driver fit? > > > >Christoph Baumann recently started porting the Freescale's driver to > >newer release. > > > >http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181569.html > > > >This needs quite a lot of work, but it's ongoing. > > > >Also, about where to put such a driver, I started a discussion about > >this last week. Mostly, that would be part of MTD, from what is out of > >the discussion so far. > > > >http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/182002.html > > I was talking about RTC persistent bits, not OTP bits, but I they > also fit in your EEPROM like model. I like it! Oops, sorry, I read your mail too quickly. But it's true that it would fit quite well in the EEPROM stuff we're discussing. Feel free to participate, and I'll let you know if something come out of it. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MXS persistent bits driver
Hi Hector, On Thu, Jul 11, 2013 at 09:30:34AM +0200, Hector Palacios wrote: > Greetings, > > Linux 2.6.35 had a driver for sysfs access to the MXS persistent > bits (drivers/misc/mxs-persistent.c). Freescale's 2.6.35 I suspect, right? > I haven't seen this is supported upstream. Is anybody working on that? > Where would such a driver fit? Christoph Baumann recently started porting the Freescale's driver to newer release. http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181569.html This needs quite a lot of work, but it's ongoing. Also, about where to put such a driver, I started a discussion about this last week. Mostly, that would be part of MTD, from what is out of the discussion so far. http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/182002.html Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MXS persistent bits driver
Hi Hector, On Thu, Jul 11, 2013 at 09:30:34AM +0200, Hector Palacios wrote: Greetings, Linux 2.6.35 had a driver for sysfs access to the MXS persistent bits (drivers/misc/mxs-persistent.c). Freescale's 2.6.35 I suspect, right? I haven't seen this is supported upstream. Is anybody working on that? Where would such a driver fit? Christoph Baumann recently started porting the Freescale's driver to newer release. http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181569.html This needs quite a lot of work, but it's ongoing. Also, about where to put such a driver, I started a discussion about this last week. Mostly, that would be part of MTD, from what is out of the discussion so far. http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/182002.html Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MXS persistent bits driver
Hi Hector, On Thu, Jul 11, 2013 at 10:56:42AM +0200, Hector Palacios wrote: On 07/11/2013 10:24 AM, maxime.rip...@free-electrons.com wrote: I haven't seen this is supported upstream. Is anybody working on that? Where would such a driver fit? Christoph Baumann recently started porting the Freescale's driver to newer release. http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181569.html This needs quite a lot of work, but it's ongoing. Also, about where to put such a driver, I started a discussion about this last week. Mostly, that would be part of MTD, from what is out of the discussion so far. http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/182002.html I was talking about RTC persistent bits, not OTP bits, but I they also fit in your EEPROM like model. I like it! Oops, sorry, I read your mail too quickly. But it's true that it would fit quite well in the EEPROM stuff we're discussing. Feel free to participate, and I'll let you know if something come out of it. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH RESEND] video: mxsfb: fix color settings for 18bit data bus and 32bpp
Hi Jean-Christophe, On Tue, Jun 18, 2013 at 10:44:17AM +0200, Hector Palacios wrote: > For a combination of 18bit LCD data bus width and a color > mode of 32bpp, the driver was setting the color mapping to > rgb666, which is wrong, as the color in memory realy has an > rgb888 layout. > > This patch also removes the setting of flag CTRL_DF24 that > makes the driver dimiss the upper 2 bits when handling 32/24bpp > colors in a diplay with 18bit data bus width. This flag made > true color images display wrong in such configurations. > > Finally, the color mapping rgb666 has also been removed as nobody > is using it and high level applications like Qt5 cannot work > with it either. > > Reference: https://lkml.org/lkml/2013/5/23/220 > Signed-off-by: Hector Palacios > Acked-by: Juergen Beisert > Acked-by: Maxime Ripard I don't see this patch in your for-next branch. It would be really great to have it for 3.11 if possible. Could you take a look at this patch please? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH RESEND] video: mxsfb: fix color settings for 18bit data bus and 32bpp
Hi Jean-Christophe, On Tue, Jun 18, 2013 at 10:44:17AM +0200, Hector Palacios wrote: For a combination of 18bit LCD data bus width and a color mode of 32bpp, the driver was setting the color mapping to rgb666, which is wrong, as the color in memory realy has an rgb888 layout. This patch also removes the setting of flag CTRL_DF24 that makes the driver dimiss the upper 2 bits when handling 32/24bpp colors in a diplay with 18bit data bus width. This flag made true color images display wrong in such configurations. Finally, the color mapping rgb666 has also been removed as nobody is using it and high level applications like Qt5 cannot work with it either. Reference: https://lkml.org/lkml/2013/5/23/220 Signed-off-by: Hector Palacios hector.palac...@digi.com Acked-by: Juergen Beisert j...@pengutronix.de Acked-by: Maxime Ripard maxime.rip...@free-electrons.com I don't see this patch in your for-next branch. It would be really great to have it for 3.11 if possible. Could you take a look at this patch please? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH] video: mxsfb: fix color settings for 18bit data bus and 32bpp
Hi Hector, On Fri, Jun 07, 2013 at 11:02:28AM +0200, maxime.rip...@free-electrons.com wrote: > On Fri, Jun 07, 2013 at 10:10:39AM +0200, Hector Palacios wrote: > > For a combination of 18bit LCD data bus width and a color > > mode of 32bpp, the driver was setting the color mapping to > > rgb666, which is wrong, as the color in memory realy has an > > rgb888 layout. > > > > This patch also removes the setting of flag CTRL_DF24 that > > makes the driver dimiss the upper 2 bits when handling 32/24bpp > > colors in a diplay with 18bit data bus width. This flag made > > true color images display wrong in such configurations. > > > > Finally, the color mapping rgb666 has also been removed as nobody > > is using it and high level applications like Qt5 cannot work > > with it either. > > > > Reference: https://lkml.org/lkml/2013/5/23/220 > > Signed-off-by: Hector Palacios > > Acked-by: Juergen Beisert > > Acked-by: Maxime Ripard > > Please also note that fbdev is now maintained by Jean Christophe > Plagniol-Villard (plagn...@jcrosoft.com, in CC), and that he is away > until the 10th of June, so maybe it should be safe to resend it to him > after this date. It seems like Jean-Christophe is back online, maybe you should resend him the patch now, it would be great to have it for 3.11. Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: mxsfb: fix color settings for 18bit data bus and 32bpp
Hi Hector, On Fri, Jun 07, 2013 at 11:02:28AM +0200, maxime.rip...@free-electrons.com wrote: On Fri, Jun 07, 2013 at 10:10:39AM +0200, Hector Palacios wrote: For a combination of 18bit LCD data bus width and a color mode of 32bpp, the driver was setting the color mapping to rgb666, which is wrong, as the color in memory realy has an rgb888 layout. This patch also removes the setting of flag CTRL_DF24 that makes the driver dimiss the upper 2 bits when handling 32/24bpp colors in a diplay with 18bit data bus width. This flag made true color images display wrong in such configurations. Finally, the color mapping rgb666 has also been removed as nobody is using it and high level applications like Qt5 cannot work with it either. Reference: https://lkml.org/lkml/2013/5/23/220 Signed-off-by: Hector Palacios hector.palac...@digi.com Acked-by: Juergen Beisert j...@pengutronix.de Acked-by: Maxime Ripard maxime.rip...@free-electrons.com Please also note that fbdev is now maintained by Jean Christophe Plagniol-Villard (plagn...@jcrosoft.com, in CC), and that he is away until the 10th of June, so maybe it should be safe to resend it to him after this date. It seems like Jean-Christophe is back online, maybe you should resend him the patch now, it would be great to have it for 3.11. Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: mxsfb: fix color settings for 18bit data bus and 32bpp
Hi Hector, On Fri, Jun 07, 2013 at 10:10:39AM +0200, Hector Palacios wrote: > For a combination of 18bit LCD data bus width and a color > mode of 32bpp, the driver was setting the color mapping to > rgb666, which is wrong, as the color in memory realy has an > rgb888 layout. > > This patch also removes the setting of flag CTRL_DF24 that > makes the driver dimiss the upper 2 bits when handling 32/24bpp > colors in a diplay with 18bit data bus width. This flag made > true color images display wrong in such configurations. > > Finally, the color mapping rgb666 has also been removed as nobody > is using it and high level applications like Qt5 cannot work > with it either. > > Reference: https://lkml.org/lkml/2013/5/23/220 > Signed-off-by: Hector Palacios > Acked-by: Juergen Beisert Acked-by: Maxime Ripard Please also note that fbdev is now maintained by Jean Christophe Plagniol-Villard (plagn...@jcrosoft.com, in CC), and that he is away until the 10th of June, so maybe it should be safe to resend it to him after this date. Thanks! Maxime -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mxsfb: DATA_FORMAT_24_BIT flag outputs invalid colours
On Fri, Jun 07, 2013 at 09:28:32AM +0200, Hector Palacios wrote: > I wasn't sure that everybody involved agreed with the patch. > @Juergen, would the patch break your platform? > Additionally, the guys from Crystalfontz didn't comment on it, but > their platform is also using a 18bit data bus width and 32bpp. We (Free Electrons) are doing the bring up for the Crystalfontz boards, so it's fine :) Thanks! Maxime -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mxsfb: DATA_FORMAT_24_BIT flag outputs invalid colours
Hi Hector, On Fri, May 24, 2013 at 03:33:19PM +0200, Juergen Beisert wrote: > Someone told me, Qt5 cannot handle this special RGB666 mode (even not the > def_rgb666_shift memory layout mentioned above). My test are based on Qt4. > Qt5 needs a regular RGB888 mode, which should silently be converted > internally to RGB666 in the hardware. > > So, your patch to always use the RGB888 memory layout seems to be the right > way to go. Do you plan on submitting this patch? (Or did you already submit it and I overlooked it?) Thanks, Maxime -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mxsfb: DATA_FORMAT_24_BIT flag outputs invalid colours
Hi Hector, On Fri, May 24, 2013 at 03:33:19PM +0200, Juergen Beisert wrote: Someone told me, Qt5 cannot handle this special RGB666 mode (even not the def_rgb666_shift memory layout mentioned above). My test are based on Qt4. Qt5 needs a regular RGB888 mode, which should silently be converted internally to RGB666 in the hardware. So, your patch to always use the RGB888 memory layout seems to be the right way to go. Do you plan on submitting this patch? (Or did you already submit it and I overlooked it?) Thanks, Maxime -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mxsfb: DATA_FORMAT_24_BIT flag outputs invalid colours
On Fri, Jun 07, 2013 at 09:28:32AM +0200, Hector Palacios wrote: I wasn't sure that everybody involved agreed with the patch. @Juergen, would the patch break your platform? Additionally, the guys from Crystalfontz didn't comment on it, but their platform is also using a 18bit data bus width and 32bpp. We (Free Electrons) are doing the bring up for the Crystalfontz boards, so it's fine :) Thanks! Maxime -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: mxsfb: fix color settings for 18bit data bus and 32bpp
Hi Hector, On Fri, Jun 07, 2013 at 10:10:39AM +0200, Hector Palacios wrote: For a combination of 18bit LCD data bus width and a color mode of 32bpp, the driver was setting the color mapping to rgb666, which is wrong, as the color in memory realy has an rgb888 layout. This patch also removes the setting of flag CTRL_DF24 that makes the driver dimiss the upper 2 bits when handling 32/24bpp colors in a diplay with 18bit data bus width. This flag made true color images display wrong in such configurations. Finally, the color mapping rgb666 has also been removed as nobody is using it and high level applications like Qt5 cannot work with it either. Reference: https://lkml.org/lkml/2013/5/23/220 Signed-off-by: Hector Palacios hector.palac...@digi.com Acked-by: Juergen Beisert j...@pengutronix.de Acked-by: Maxime Ripard maxime.rip...@free-electrons.com Please also note that fbdev is now maintained by Jean Christophe Plagniol-Villard (plagn...@jcrosoft.com, in CC), and that he is away until the 10th of June, so maybe it should be safe to resend it to him after this date. Thanks! Maxime -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mxsfb: DATA_FORMAT_24_BIT flag outputs invalid colours
Hi Juergen,
On Thu, May 23, 2013 at 03:31:31PM +0200, Juergen Beisert wrote:
> Hi Maxime,
>
> maxime.rip...@free-electrons.com wrote:
> > On Thu, May 23, 2013 at 01:55:28PM +0200, Hector Palacios wrote:
> > > I'm using an i.MX28 based board with lcd connected with 18bits data bus.
> > > My platform uses 32 bits per pixel:
> > >
> > > mxsfb_pdata.default_bpp = 32;
> > > mxsfb_pdata.ld_intf_width = STMLCDIF_18BIT;
> > >
> > > With these settings the mxsfb.c driver sets flag DATA_FORMAT_24_BIT
> > > at HW_LCDIF_CTRL register in function mxsfb_set_par():
> > >
> > > case 32:
> > > dev_dbg(>pdev->dev, "Setting up RGB888/666 mode\n");
> > > ctrl |= CTRL_SET_WORD_LENGTH(3);
> > > switch (host->ld_intf_width) {
> > > case STMLCDIF_8BIT:
> > > dev_dbg(>pdev->dev,
> > > "Unsupported LCD bus width mapping\n");
> > > return -EINVAL;
> > > case STMLCDIF_16BIT:
> > > case STMLCDIF_18BIT:
> > > /* 24 bit to 18 bit mapping */
> > > ctrl |= CTRL_DF24; /* ignore the upper 2 bits in
> > > * each colour component
> > > */
> > > break;
> > > case STMLCDIF_24BIT:
> > > /* real 24 bit */
> > > break;
> > > }
> > >
> > > According to the manual, this flag does:
> > > 0x0: ALL_24_BITS_VALID: Data input to the block is in 24 bpp
> > > format, such that all RGB 888 data is contained in 24 bits.
> > > 0x1: DROP_UPPER_2_BITS_PER_BYTE — Data input to the block is
> > > actually RGB 18 bpp, but there is 1 colour per byte, hence the upper
> > > 2 bits in each byte do not contain any useful data, and should be
> > > dropped.
> > >
> > > The setting of this flag is producing bad colours with true colour
> > > images (i.e. the Linux penguin is displayed ok, but QT applications
> > > or images displayed with fbv are not).
> > > I believe the setting of this flag is not correct (after all, if my
> > > bpp is 32, then all 24bit colours are useful and dropping the upper
> > > 2 bits is a bad idea).
> > > If I don't set it, then true colour images are displayed correctly.
> > > The only problem is that the Linux penguin is displayed much darker
> > > than usual (correct colours, but darker). Perhaps the 224 colour
> > > format of this image justifies it?
> > >
> > > I noticed the cfa10049 platform also uses the same configuration (18
> > > bits data bus and 32bpp) and was wondering if true colour images are
> > > correctly displayed in this platform with this flag set (for example
> > > with fbv application [1]).
> >
> > I had the exact same problem, and suggested the exact same solution a
> > few weeks back.
> >
> > https://patchwork.kernel.org/patch/2470441/
> >
> > The conclusion of that discussion what that the userspace applications
> > were not honouring the bitfield correctly set by the mxsfb driver, and
> > as such, it was not a bug in the driver.
> >
> > While this is correct, I wonder, now that since we had that same problem
> > in a very short amount of time, if we couldn't set this behaviour
> > dependant of some (dt? kernel argument?) property so that one could
> > customise it anyway he want.
> >
> > Maxime
>
> i.MX2[3|8]LCD1 LCD2 LCD3
> 24bit 18bit 18bit
>
> LCD_D0 B0 B0 --
> LCD_D1 B1 B1 --
> LCD_D2 B2 B2 B0
> LCD_D3 B3 B3 B1
> LCD_D4 B4 B4 B2
> LCD_D5 B5 B5 B3
> LCD_D6 B6 G0 B4
> LCD_D7 B7 G1 B5
>
> LCD_D8 G0 G2 --
> LCD_D9 G1 G3 --
> LCD_D10G2 G4 G0
> LCD_D11G3 G5 G1
> LCD_D12G4 R0 G2
> LCD_D13G5 R1 G3
> LCD_D14G6 R2 G4
> LCD_D15G7 R3 G5
>
> LCD_D16R0 R4 --
> LCD_D17R1 R5 --
> LCD_D18R2
Re: mxsfb: DATA_FORMAT_24_BIT flag outputs invalid colours
Hi Juergen,
On Thu, May 23, 2013 at 03:31:31PM +0200, Juergen Beisert wrote:
Hi Maxime,
maxime.rip...@free-electrons.com wrote:
On Thu, May 23, 2013 at 01:55:28PM +0200, Hector Palacios wrote:
I'm using an i.MX28 based board with lcd connected with 18bits data bus.
My platform uses 32 bits per pixel:
mxsfb_pdata.default_bpp = 32;
mxsfb_pdata.ld_intf_width = STMLCDIF_18BIT;
With these settings the mxsfb.c driver sets flag DATA_FORMAT_24_BIT
at HW_LCDIF_CTRL register in function mxsfb_set_par():
case 32:
dev_dbg(host-pdev-dev, Setting up RGB888/666 mode\n);
ctrl |= CTRL_SET_WORD_LENGTH(3);
switch (host-ld_intf_width) {
case STMLCDIF_8BIT:
dev_dbg(host-pdev-dev,
Unsupported LCD bus width mapping\n);
return -EINVAL;
case STMLCDIF_16BIT:
case STMLCDIF_18BIT:
/* 24 bit to 18 bit mapping */
ctrl |= CTRL_DF24; /* ignore the upper 2 bits in
* each colour component
*/
break;
case STMLCDIF_24BIT:
/* real 24 bit */
break;
}
According to the manual, this flag does:
0x0: ALL_24_BITS_VALID: Data input to the block is in 24 bpp
format, such that all RGB 888 data is contained in 24 bits.
0x1: DROP_UPPER_2_BITS_PER_BYTE — Data input to the block is
actually RGB 18 bpp, but there is 1 colour per byte, hence the upper
2 bits in each byte do not contain any useful data, and should be
dropped.
The setting of this flag is producing bad colours with true colour
images (i.e. the Linux penguin is displayed ok, but QT applications
or images displayed with fbv are not).
I believe the setting of this flag is not correct (after all, if my
bpp is 32, then all 24bit colours are useful and dropping the upper
2 bits is a bad idea).
If I don't set it, then true colour images are displayed correctly.
The only problem is that the Linux penguin is displayed much darker
than usual (correct colours, but darker). Perhaps the 224 colour
format of this image justifies it?
I noticed the cfa10049 platform also uses the same configuration (18
bits data bus and 32bpp) and was wondering if true colour images are
correctly displayed in this platform with this flag set (for example
with fbv application [1]).
I had the exact same problem, and suggested the exact same solution a
few weeks back.
https://patchwork.kernel.org/patch/2470441/
The conclusion of that discussion what that the userspace applications
were not honouring the bitfield correctly set by the mxsfb driver, and
as such, it was not a bug in the driver.
While this is correct, I wonder, now that since we had that same problem
in a very short amount of time, if we couldn't set this behaviour
dependant of some (dt? kernel argument?) property so that one could
customise it anyway he want.
Maxime
i.MX2[3|8]LCD1 LCD2 LCD3
24bit 18bit 18bit
LCD_D0 B0 B0 --
LCD_D1 B1 B1 --
LCD_D2 B2 B2 B0
LCD_D3 B3 B3 B1
LCD_D4 B4 B4 B2
LCD_D5 B5 B5 B3
LCD_D6 B6 G0 B4
LCD_D7 B7 G1 B5
LCD_D8 G0 G2 --
LCD_D9 G1 G3 --
LCD_D10G2 G4 G0
LCD_D11G3 G5 G1
LCD_D12G4 R0 G2
LCD_D13G5 R1 G3
LCD_D14G6 R2 G4
LCD_D15G7 R3 G5
LCD_D16R0 R4 --
LCD_D17R1 R5 --
LCD_D18R2R0
LCD_D19R3R1
LCD_D20R4R2
LCD_D21R5R3
LCD_D22R6R4
LCD_D23R7R5
Is your display connected like LCD2 or LCD3? LCD3 must still handled like a
24
bit display shown in LCD1, while only the LCD2-case is the 24 bit to 18 bit
mapping case.
At least my current tests with an i.MX23 and a connection like LCD2 are
working here with a Qt application. Qt honours the pixel bitfield
description. And I'm using the bits-per-pixel = 32 and bus-width = 18
entries in the device tree.
I'm in the second case, so with the same setup that you have it seems.
Don't get me wrong, I was not saying that the driver was flawed or had a
bug, I understood very well your arguments when I first submitted the
patch. The problem is more for all the userspace applications
Re: mxsfb: DATA_FORMAT_24_BIT flag outputs invalid colours
Hi Hector,
On Thu, May 23, 2013 at 01:55:28PM +0200, Hector Palacios wrote:
> Hello,
>
> I'm using an i.MX28 based board with lcd connected with 18bits data bus.
> My platform uses 32 bits per pixel:
>
> mxsfb_pdata.default_bpp = 32;
> mxsfb_pdata.ld_intf_width = STMLCDIF_18BIT;
>
> With these settings the mxsfb.c driver sets flag DATA_FORMAT_24_BIT
> at HW_LCDIF_CTRL register in function mxsfb_set_par():
>
> case 32:
> dev_dbg(>pdev->dev, "Setting up RGB888/666 mode\n");
> ctrl |= CTRL_SET_WORD_LENGTH(3);
> switch (host->ld_intf_width) {
> case STMLCDIF_8BIT:
> dev_dbg(>pdev->dev,
> "Unsupported LCD bus width mapping\n");
> return -EINVAL;
> case STMLCDIF_16BIT:
> case STMLCDIF_18BIT:
> /* 24 bit to 18 bit mapping */
> ctrl |= CTRL_DF24; /* ignore the upper 2 bits in
> * each colour component
> */
> break;
> case STMLCDIF_24BIT:
> /* real 24 bit */
> break;
> }
>
> According to the manual, this flag does:
> 0x0: ALL_24_BITS_VALID: Data input to the block is in 24 bpp
> format, such that all RGB 888 data is contained in 24 bits.
> 0x1: DROP_UPPER_2_BITS_PER_BYTE — Data input to the block is
> actually RGB 18 bpp, but there is 1 colour per byte, hence the upper
> 2 bits in each byte do not contain any useful data, and should be
> dropped.
>
> The setting of this flag is producing bad colours with true colour
> images (i.e. the Linux penguin is displayed ok, but QT applications
> or images displayed with fbv are not).
> I believe the setting of this flag is not correct (after all, if my
> bpp is 32, then all 24bit colours are useful and dropping the upper
> 2 bits is a bad idea).
> If I don't set it, then true colour images are displayed correctly.
> The only problem is that the Linux penguin is displayed much darker
> than usual (correct colours, but darker). Perhaps the 224 colour
> format of this image justifies it?
>
> I noticed the cfa10049 platform also uses the same configuration (18
> bits data bus and 32bpp) and was wondering if true colour images are
> correctly displayed in this platform with this flag set (for example
> with fbv application [1]).
I had the exact same problem, and suggested the exact same solution a
few weeks back.
https://patchwork.kernel.org/patch/2470441/
The conclusion of that discussion what that the userspace applications
were not honouring the bitfield correctly set by the mxsfb driver, and
as such, it was not a bug in the driver.
While this is correct, I wonder, now that since we had that same problem
in a very short amount of time, if we couldn't set this behaviour
dependant of some (dt? kernel argument?) property so that one could
customise it anyway he want.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mxsfb: DATA_FORMAT_24_BIT flag outputs invalid colours
Hi Hector,
On Thu, May 23, 2013 at 01:55:28PM +0200, Hector Palacios wrote:
Hello,
I'm using an i.MX28 based board with lcd connected with 18bits data bus.
My platform uses 32 bits per pixel:
mxsfb_pdata.default_bpp = 32;
mxsfb_pdata.ld_intf_width = STMLCDIF_18BIT;
With these settings the mxsfb.c driver sets flag DATA_FORMAT_24_BIT
at HW_LCDIF_CTRL register in function mxsfb_set_par():
case 32:
dev_dbg(host-pdev-dev, Setting up RGB888/666 mode\n);
ctrl |= CTRL_SET_WORD_LENGTH(3);
switch (host-ld_intf_width) {
case STMLCDIF_8BIT:
dev_dbg(host-pdev-dev,
Unsupported LCD bus width mapping\n);
return -EINVAL;
case STMLCDIF_16BIT:
case STMLCDIF_18BIT:
/* 24 bit to 18 bit mapping */
ctrl |= CTRL_DF24; /* ignore the upper 2 bits in
* each colour component
*/
break;
case STMLCDIF_24BIT:
/* real 24 bit */
break;
}
According to the manual, this flag does:
0x0: ALL_24_BITS_VALID: Data input to the block is in 24 bpp
format, such that all RGB 888 data is contained in 24 bits.
0x1: DROP_UPPER_2_BITS_PER_BYTE — Data input to the block is
actually RGB 18 bpp, but there is 1 colour per byte, hence the upper
2 bits in each byte do not contain any useful data, and should be
dropped.
The setting of this flag is producing bad colours with true colour
images (i.e. the Linux penguin is displayed ok, but QT applications
or images displayed with fbv are not).
I believe the setting of this flag is not correct (after all, if my
bpp is 32, then all 24bit colours are useful and dropping the upper
2 bits is a bad idea).
If I don't set it, then true colour images are displayed correctly.
The only problem is that the Linux penguin is displayed much darker
than usual (correct colours, but darker). Perhaps the 224 colour
format of this image justifies it?
I noticed the cfa10049 platform also uses the same configuration (18
bits data bus and 32bpp) and was wondering if true colour images are
correctly displayed in this platform with this flag set (for example
with fbv application [1]).
I had the exact same problem, and suggested the exact same solution a
few weeks back.
https://patchwork.kernel.org/patch/2470441/
The conclusion of that discussion what that the userspace applications
were not honouring the bitfield correctly set by the mxsfb driver, and
as such, it was not a bug in the driver.
While this is correct, I wonder, now that since we had that same problem
in a very short amount of time, if we couldn't set this behaviour
dependant of some (dt? kernel argument?) property so that one could
customise it anyway he want.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Drop support for x86-32
A 32-bit kernel on a legacy (or even new) system in 2017 will still need > regular kernel updates (not \"long term\" un0maintained kernels) > in order to work with new USB devices, new 4KB+ sector hard drives, > newer generations of SSDs, etc.. 12-years-old machine is trash. If someone can buy e.g. new hard drive, he can also afford to buy newer PC. New hard drive in 2017 will be likely incompatible with 12-years-old machine in such way which can\'t be fixed by new kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Drop support for x86-32
A 32-bit kernel on a legacy (or even new) system in 2017 will still need regular kernel updates (not \long term\ un0maintained kernels) in order to work with new USB devices, new 4KB+ sector hard drives, newer generations of SSDs, etc.. 12-years-old machine is trash. If someone can buy e.g. new hard drive, he can also afford to buy newer PC. New hard drive in 2017 will be likely incompatible with 12-years-old machine in such way which can\'t be fixed by new kernel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.21-rt2
Hi, |--==> Ingo Molnar writes: IM> i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded IM> from the usual place: IM> http://redhat.com/~mingo/realtime-preempt/ This new version of the patch solves the amd64/udev bug I reported against previous releases: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00353.html I'm going to test the patch on other amd64 machines as well, thanks a lot and keep up goo the work! Ciao, Free - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.21-rt2
Hi, |--== Ingo Molnar writes: IM i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded IM from the usual place: IM http://redhat.com/~mingo/realtime-preempt/ This new version of the patch solves the amd64/udev bug I reported against previous releases: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00353.html I'm going to test the patch on other amd64 machines as well, thanks a lot and keep up goo the work! Ciao, Free - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.21-rt1
Hi, |--==> Ingo Molnar writes: IM> i have released the v2.6.20-rt1 kernel, which can be downloaded from the IM> usual place: IM> http://redhat.com/~mingo/realtime-preempt/ IM> more info about the -rt patchset can be found in the RT wiki: IM> http://rt.wiki.kernel.org IM> This is a fixes-only release. IM> to build a 2.6.21-rt1 tree, the following patches should be applied: IM> http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.tar.bz2 IM> http://redhat.com/~mingo/realtime-preempt/patch-2.6.21-rt1 I've tested the patch on a Pavillon zv5000 laptop (amd64) and apparently the kernel still hangs when one of the script in the initramfs [0] tries to run udevsettle. Booting with noapic doesn't seem to help, and differently from the 2.6.21-rc6-rt0 release [1] this time the kernel won't boot even with qemu. Here's the config I used: http://people.64studio.com/~free/config-2.6.21-rt1 Ciao, Free [0] http://people.64studio.com/~free/udev [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg00332.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.21-rt1
Hi, |--== Ingo Molnar writes: IM i have released the v2.6.20-rt1 kernel, which can be downloaded from the IM usual place: IM http://redhat.com/~mingo/realtime-preempt/ IM more info about the -rt patchset can be found in the RT wiki: IM http://rt.wiki.kernel.org IM This is a fixes-only release. IM to build a 2.6.21-rt1 tree, the following patches should be applied: IM http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.tar.bz2 IM http://redhat.com/~mingo/realtime-preempt/patch-2.6.21-rt1 I've tested the patch on a Pavillon zv5000 laptop (amd64) and apparently the kernel still hangs when one of the script in the initramfs [0] tries to run udevsettle. Booting with noapic doesn't seem to help, and differently from the 2.6.21-rc6-rt0 release [1] this time the kernel won't boot even with qemu. Here's the config I used: http://people.64studio.com/~free/config-2.6.21-rt1 Ciao, Free [0] http://people.64studio.com/~free/udev [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg00332.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
