Re: New sysfs interface for privacy screens
On Thu, 03 Oct 2019, Daniel Thompson wrote: > I guess... although the Thinkpad code hasn't added any standard > interfaces (no other laptop should be placing controls for a privacy > screen in /proc/acpi/ibm/... ). Maybe its not too late. As far as I am concerned, it is *not* too late. And you can always have a driver-private way of messing with something, and a more generic way of doing the same thing. thinkpad-acpi will always welcome patches switching to the new generic way (as long as we can have a deprecation period *for long-time-used facilities* -- which is not the case of the privacy screen, no deprecation period need there). The privacy thing is too new, feel free to design a generic one and send in a patch *switching* thinkpad-acpi to the new generic one. I would ACK that. If the subsystem maintainer also agrees, (and nobody *seriously* complain about it from userspace), the private interface would be gone just like that. -- Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbcon: warn on invalid cursor blink intervals
On Fri, 20 May 2016, Scot Doyle wrote: > On Fri, 20 May 2016, Jeremy Kerr wrote: > > >Then looks there are two fix patches acked & tested: > > > > > > - the patch in this thread > > > - another one "[PATCH] tty: vt: Fix soft lockup in fbcon cursor > > >blink timer." > > > https://lkml.org/lkml/2016/5/17/455 > > > > > >So which one will be pushed to linus? > > > > Not that it's my call, but we may want both; the first as a safety > > measure to prevent an invalid cur_blink_jiffies ever being set, and the > > second one to actually fix the initialisation of vc_cur_blink_ms (and > > address the warning introduced by the first). > > Tomi / Greg, > > I'd suggest > - applying "tty: vt: Fix soft lockup in fbcon cursor blink timer." to 4.7 and > stable[4.2] > - applying "fbcon: warn on invalid cursor blink intervals" to 4.7 > - ignoring "fbcon: use default if cursor blink interval is not valid" > > Note: the patches don't depend on each other I applied both recommended patches on top of 4.4.11 for testing, and they made things a lot better here. I suggest the second patch should be backported to stable too, might as well fix this thing for good *and keep the door closed*. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
[PATCH] fbcon: warn on invalid cursor blink intervals
On Thu, 19 May 2016, Scot Doyle wrote: > Two systems are locking on boot [1] because ops->cur_blink_jiffies > is set to zero from vc->vc_cur_blink_ms. > > Ignore such invalid intervals and log a warning. > > [1] https://bugs.launchpad.net/bugs/1574814 > > Suggested-by: David Daney > Signed-off-by: Scot Doyle > Cc: [v4.2] FWIW: Tested-by: Henrique de Moraes Holschuh on top of 4.4.11. And nothing caused it to issue warnings here, so far (with the other recommended patch applied first). > --- > drivers/video/console/fbcon.c | 14 -- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c > index 6e92917..fad5b89 100644 > --- a/drivers/video/console/fbcon.c > +++ b/drivers/video/console/fbcon.c > @@ -1095,7 +1095,13 @@ static void fbcon_init(struct vc_data *vc, int init) > con_copy_unimap(vc, svc); > > ops = info->fbcon_par; > - ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms); > + > + if (vc->vc_cur_blink_ms >= 50) > + ops->cur_blink_jiffies = > + msecs_to_jiffies(vc->vc_cur_blink_ms); > + else > + WARN_ONCE(1, "blink interval < 50 ms"); > + > p->con_rotate = initial_rotation; > set_blitting_type(vc, info); > > @@ -1309,7 +1315,11 @@ static void fbcon_cursor(struct vc_data *vc, int mode) > int y; > int c = scr_readw((u16 *) vc->vc_pos); > > - ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms); > + if (vc->vc_cur_blink_ms >= 50) > + ops->cur_blink_jiffies = > + msecs_to_jiffies(vc->vc_cur_blink_ms); > + else > + WARN_ONCE(1, "blink interval < 50 ms"); > > if (fbcon_is_inactive(vc, info) || vc->vc_deccm != 1) > return; -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
[PATCH] tty: vt: Fix soft lockup in fbcon cursor blink timer.
On Tue, 17 May 2016, David Daney wrote: > From: David Daney > We are getting somewhat random soft lockups with this signature: > > [ 86.992215] [] el1_irq+0xa0/0x10c > [ 86.997082] [] cursor_timer_handler+0x30/0x54 > [ 87.002991] [] call_timer_fn+0x54/0x1a8 > [ 87.008378] [] run_timer_softirq+0x1c4/0x2bc > [ 87.014200] [] __do_softirq+0x114/0x344 > [ 87.019590] [] irq_exit+0x74/0x98 > [ 87.024458] [] __handle_domain_irq+0x98/0xfc > [ 87.030278] [] gic_handle_irq+0x94/0x190 > > This is caused by the vt visual_init() function calling into > fbcon_init() with a vc_cur_blink_ms value of zero. This is a > transient condition, as it is later set to a non-zero value. But, if > the timer happens to expire while the blink rate is zero, it goes into > an endless loop, and we get soft lockup. > > The fix is to initialize vc_cur_blink_ms before calling the con_init() > function. > > Signed-off-by: David Daney > Cc: stable at vger.kernel.org Tested-by: Henrique de Moraes Holschuh on top of 4.4.11. > --- > drivers/tty/vt/vt.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c > index 3e3c757..eef5c36 100644 > --- a/drivers/tty/vt/vt.c > +++ b/drivers/tty/vt/vt.c > @@ -750,6 +750,7 @@ static void visual_init(struct vc_data *vc, int num, int > init) > vc->vc_complement_mask = 0; > vc->vc_can_do_color = 0; > vc->vc_panic_force_write = false; > + vc->vc_cur_blink_ms = DEFAULT_CURSOR_BLINK_MS; > vc->vc_sw->con_init(vc, init); > if (!vc->vc_complement_mask) > vc->vc_complement_mask = vc->vc_can_do_color ? 0x7700 : 0x0800; -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
[PATCH 29/32] thinkpad-acpi: Port to new backlight interface selection API
On Wed, Jun 10, 2015, at 10:01, Hans de Goede wrote:
> Port the backlight selection logic to the new backlight interface
> selection API.
>
> Signed-off-by: Hans de Goede
Acked-by: Henrique de Moraes Holschuh
> ---
> drivers/platform/x86/thinkpad_acpi.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c
> b/drivers/platform/x86/thinkpad_acpi.c
> index 28f3281..33e488c 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -83,6 +83,7 @@
> #include
> #include
> #include
> +#include
>
> /* ThinkPad CMOS commands */
> #define TP_CMOS_VOLUME_DOWN 0
> @@ -3487,7 +3488,7 @@ static int __init hotkey_init(struct
> ibm_init_struct *iibm)
> /* Do not issue duplicate brightness change events to
>* userspace. tpacpi_detect_brightness_capabilities() must have
>* been called before this point */
> - if (acpi_video_backlight_support()) {
> + if (acpi_video_get_backlight_type() != acpi_backlight_vendor) {
> pr_info("This ThinkPad has standard ACPI backlight "
> "brightness control, supported by the ACPI "
> "video driver\n");
> @@ -6491,7 +6492,7 @@ static int __init brightness_init(struct
> ibm_init_struct *iibm)
> return 1;
> }
>
> - if (acpi_video_backlight_support()) {
> + if (acpi_video_get_backlight_type() != acpi_backlight_vendor) {
> if (brightness_enable > 1) {
> pr_info("Standard ACPI backlight interface "
> "available, not loading native one\n");
> --
> 2.4.2
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Re: [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
On Thu, 26 Sep 2013, Aaron Lu wrote: I checked the git log for the commit to use tpacpi_acpi_handle_locate to locate video controller's ACPI handle, it's: commit 122f26726b5e16174bf8a707df14be1d93c49d62 Author: Henrique de Moraes Holschuh h...@hmh.eng.br Date: Mon Aug 9 23:48:18 2010 -0300 Yeah... So I checked out that commit and found that it shouldn't work either, since it has the same problem of the current code. The ACPI video controller device is given an id of ACPI_VIDEO_HID, but it's only known to Linux ACPI, not ACPICA, so the function provided by ACPICA acpi_get_devices will not work in this case, as that function will really check the control method of _HID under the handle, which does not exist no matter if Linux ACPI has added an id to its device structure or not. OTOH, the function provided by Linux ACPI acpi_device_hid will see the added id. In a word, the add of the HID will not affect the ASL namespace layout of the device node(thus, no _HID control method will be added to the device node). Erk. It went broken for a long time, and the users didn't notice(!)... commit ff413195e830541afeae469fc866ecd0319abd7e Author: Alex Hung alex.h...@canonical.com Date: Tue Apr 24 16:40:52 2012 +0800 thinkpad-acpi: fix issuing duplicated key events for brightness up/down The tp_features.bright_acpimode will not be set correctly for brightness control because ACPI_VIDEO_HID will not be located in ACPI. As a result, a duplicated key event will always be sent. acpi_video_backlight_support() is sufficient to detect standard ACPI brightness control. Signed-off-by: Alex Hung alex.h...@canonical.com Signed-off-by: Matthew Garrett m...@redhat.com Until that. And unfortunately I did not connect the dots at the time. Thanks for explaining the issue properly. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
On Tue, 24 Sep 2013, Aaron Lu wrote: The tpacpi_acpi_handle_locate function makes use of acpi_get_devices to locate handle for ACPI video by HID, the problem is, ACPI video node doesn't really have HID defined(i.e. no _HID control method is defined for video device), so.. that function would fail. This can be solved by enhancing the callback function for acpi_get_devices, where we can use acpi_device_hid function to check if the ACPI node corresponds to a video controller. In addition to that, the _BCL control method only exists under a video output device node, not a video controller device node. So to evaluate _BCL, we need the handle of a video output device node, which is child of the located video controller node from tpacpi_acpi_handle_locate. The two fix are necessary for some Thinkpad models to emit notification on backlight hotkey press as a result of evaluation of _BCL. Signed-off-by: Aaron Lu aaron...@intel.com Tested-by: Igor Gnatenko i.gnatenko.br...@gmail.com Some testing on a *60 (T60,X60...) would also be best, I cannot test this on my T43. Anyway, the code itself looks fine, so: Acked-by: Henrique de Moraes Holschuh h...@hmh.eng.br -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
On Fri, 27 Sep 2013, Yves-Alexis Perez wrote: On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote: Some testing on a *60 (T60,X60...) would also be best, I cannot test this on my T43. Anyway, the code itself looks fine, so: I can test on T61, would that help? I think so. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
On Tue, 24 Sep 2013, Aaron Lu wrote: locate handle for ACPI video by HID, the problem is, ACPI video node doesn't really have HID defined(i.e. no _HID control method is defined ACPI video is supposed to attach a virtual HID node (ACPI_VIDEO_HID) to ACPI video devices so as to keep the non-trivial video device detection logic in just one place instead of reinventing the wheel in every driver (which is always a recipe for disaster). When did that break? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
MTRR use in drivers
On Sun, 23 Jun 2013, H. Peter Anvin wrote: > On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote: > > > > And as far as I could find from Intel's not-that-complete public > > "specification updates", we are applying the errata workaround to a few more > > processors than strictly required, but since I have no idea how to write a > > test case, I can't whitelist the 3rd-gen Pentium M on my T43, nor can I get > > ThinkPad owners to test it for us on 1st and 2nd-gen Pentium M and report > > back. > > Which specific erratum are you referring to, here? The "WC becomes UC" > erratum? I don't think there is a sane testcase for it since it needs a > very complicated setup to trigger. There are at least two different nasty PAT issues that are not always critical, and one that outright hangs the processor (if the unsupported aliasing of WB with UC/WC happens). Interestingly enough, most of the P4-Xeons and P4 do not appear to have the "WC becomes UC" errata. However, LOTS of P4, M-P4, Xeon PIII, Xeon, and Pentium M have a bug where the four highest entries in the PAT table are inactive (aliased to the four lowest entries) in mode B (PSE) and mode C (PAE) for 4k pages. They work fine for large pages. Also, lots of them can hang if you ever alias WB with UC or WC (which is apparently an unsupported configuration anyway, or so it says in the errata). There are other weird aliasing nasties, such as one where you get memory corruption if you alias WB data with code (being accessed as UC or WC) in the same cacheline, and some stuff such as weirdness should the page table be on WC memory... I can track down most of the CPUIDs involved if you want, but someone from Intel would be better (I assume they actually have access to the errata documentation in some less idiotic way than reading a ton of badly indexed PDFs that take forever to find in their site). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
MTRR use in drivers
On Sun, 23 Jun 2013, H. Peter Anvin wrote: > On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote: > > On Sun, 23 Jun 2013, H. Peter Anvin wrote: > >> Why do you care about performance when PAT is disabled? > > > > It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and > > nobody ever took the pain to track down which ones of those actually have > > PAT+MTRR aliasing bugs. > > > > These boxes have boards like the Radeon X300, which needs either PAT or MTRR > > to not become unusable... > > We're talking hardware which is now many years old, but this is causing > very serious problems on real, modern hardware. As far as I understand > it, too, the blacklisting was precautionary (the only bug that I > personally know about is a performance bug, where WC would be > incorrectly converted to UC.) And as far as I could find from Intel's not-that-complete public "specification updates", we are applying the errata workaround to a few more processors than strictly required, but since I have no idea how to write a test case, I can't whitelist the 3rd-gen Pentium M on my T43, nor can I get ThinkPad owners to test it for us on 1st and 2nd-gen Pentium M and report back. > We need a way forward here. If it is the only way I think we would have > to sacrifice the old machines, but perhaps something can be worked out > (e.g. if PAT is disabled, fall back to MTRRs if available for ioremap_wc()). I'd be quite happy with a MTRR fallback. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
MTRR use in drivers
On Sun, 23 Jun 2013, H. Peter Anvin wrote: > Why do you care about performance when PAT is disabled? It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and nobody ever took the pain to track down which ones of those actually have PAT+MTRR aliasing bugs. These boxes have boards like the Radeon X300, which needs either PAT or MTRR to not become unusable... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: MTRR use in drivers
On Sun, 23 Jun 2013, H. Peter Anvin wrote: Why do you care about performance when PAT is disabled? It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and nobody ever took the pain to track down which ones of those actually have PAT+MTRR aliasing bugs. These boxes have boards like the Radeon X300, which needs either PAT or MTRR to not become unusable... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: MTRR use in drivers
On Sun, 23 Jun 2013, H. Peter Anvin wrote: On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote: On Sun, 23 Jun 2013, H. Peter Anvin wrote: Why do you care about performance when PAT is disabled? It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and nobody ever took the pain to track down which ones of those actually have PAT+MTRR aliasing bugs. These boxes have boards like the Radeon X300, which needs either PAT or MTRR to not become unusable... We're talking hardware which is now many years old, but this is causing very serious problems on real, modern hardware. As far as I understand it, too, the blacklisting was precautionary (the only bug that I personally know about is a performance bug, where WC would be incorrectly converted to UC.) And as far as I could find from Intel's not-that-complete public specification updates, we are applying the errata workaround to a few more processors than strictly required, but since I have no idea how to write a test case, I can't whitelist the 3rd-gen Pentium M on my T43, nor can I get ThinkPad owners to test it for us on 1st and 2nd-gen Pentium M and report back. We need a way forward here. If it is the only way I think we would have to sacrifice the old machines, but perhaps something can be worked out (e.g. if PAT is disabled, fall back to MTRRs if available for ioremap_wc()). I'd be quite happy with a MTRR fallback. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: MTRR use in drivers
On Sun, 23 Jun 2013, H. Peter Anvin wrote: On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote: And as far as I could find from Intel's not-that-complete public specification updates, we are applying the errata workaround to a few more processors than strictly required, but since I have no idea how to write a test case, I can't whitelist the 3rd-gen Pentium M on my T43, nor can I get ThinkPad owners to test it for us on 1st and 2nd-gen Pentium M and report back. Which specific erratum are you referring to, here? The WC becomes UC erratum? I don't think there is a sane testcase for it since it needs a very complicated setup to trigger. There are at least two different nasty PAT issues that are not always critical, and one that outright hangs the processor (if the unsupported aliasing of WB with UC/WC happens). Interestingly enough, most of the P4-Xeons and P4 do not appear to have the WC becomes UC errata. However, LOTS of P4, M-P4, Xeon PIII, Xeon, and Pentium M have a bug where the four highest entries in the PAT table are inactive (aliased to the four lowest entries) in mode B (PSE) and mode C (PAE) for 4k pages. They work fine for large pages. Also, lots of them can hang if you ever alias WB with UC or WC (which is apparently an unsupported configuration anyway, or so it says in the errata). There are other weird aliasing nasties, such as one where you get memory corruption if you alias WB data with code (being accessed as UC or WC) in the same cacheline, and some stuff such as weirdness should the page table be on WC memory... I can track down most of the CPUIDs involved if you want, but someone from Intel would be better (I assume they actually have access to the errata documentation in some less idiotic way than reading a ton of badly indexed PDFs that take forever to find in their site). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Kernel almost hangs when CONFIG_DRM_RADEON=y
On Tue, 30 Aug 2011, Peter Zijlstra wrote: > On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote: > > On Mon, 29 Aug 2011, Borislav Petkov wrote: > > > So, hypothetically speaking, hpa suggested then that we could pass > > > firmware blobs over the linked list setup_data thing in the real-mode > > > kernel header and parse_setup_data() can look at them and map them > > > somewhere later for the driver to find. This should be doable because > > > you're only gonna need a handful of blobs for CPU ucode, network and GPU > > > if the last is compiled in. > > > > > > I wanted to take a serious look at that for the ucode loading, maybe I > > > should try to shuffle some time for it... > > > > It would be very useful, yes. > > > > Alternatively, you could extend the initrd format to have a firmware > > directory appended after the filesystem image. ACPI is going to abuse > > the initrd in just that way to override ACPI tables very soon (patches > > have been already submitted to linux-acpi), so if a more structured and > > extensible way to piggy-back early-init data in the initrd is needed, it > > would be good to bring that to the table NOW. > > Uhm,.. does that mean that soon we can't boot kernels without initrd? > That too is a massive regression in my eyes. Well, if work starts soon enough on a bootloader extension to avoid messing with the initrd, we could refuse to set that initrd-based ACPI table override as ABI on the grounds that it is a debug thing, and later move it to the properly designed firmware bootloader extension. Maybe the grub multiboot protocol[1] is worth looking at, assuming that thing is salvagable and would actually work for both 32bit and 64bit BIOS and UEFI bootstrapping? [1]http://www.gnu.org/software/grub/manual/multiboot/multiboot.html -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Kernel almost hangs when CONFIG_DRM_RADEON=y
On Tue, 30 Aug 2011, Borislav Petkov wrote: > On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote: > > On Mon, 29 Aug 2011, Borislav Petkov wrote: > > > So, hypothetically speaking, hpa suggested then that we could pass > > > firmware blobs over the linked list setup_data thing in the real-mode > > > kernel header and parse_setup_data() can look at them and map them > > > somewhere later for the driver to find. This should be doable because > > > you're only gonna need a handful of blobs for CPU ucode, network and GPU > > > if the last is compiled in. > > > > > > I wanted to take a serious look at that for the ucode loading, maybe I > > > should try to shuffle some time for it... > > > > It would be very useful, yes. > > > > Alternatively, you could extend the initrd format to have a firmware > > directory appended after the filesystem image. ACPI is going to abuse > > the initrd in just that way to override ACPI tables very soon (patches > > have been already submitted to linux-acpi), > > .. lemme guess: they didn't put the correct tables in the BIOS in the > first place and now it is too late for a BIOS fix and want to shuffle in > all those "fixes" through initrd ontop of ACPI. Oh boy, do I love all > the ACPI crap stories :). Heh. Actually, the patches were created by a distro for debug purposes. No vendor pushed for them. But it is a safe bet that users will end up using them to work around ACPI vendor crap that will never get fixed properly through a BIOS update, etc. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Kernel almost hangs when CONFIG_DRM_RADEON=y
On Mon, 29 Aug 2011, Borislav Petkov wrote: > So, hypothetically speaking, hpa suggested then that we could pass > firmware blobs over the linked list setup_data thing in the real-mode > kernel header and parse_setup_data() can look at them and map them > somewhere later for the driver to find. This should be doable because > you're only gonna need a handful of blobs for CPU ucode, network and GPU > if the last is compiled in. > > I wanted to take a serious look at that for the ucode loading, maybe I > should try to shuffle some time for it... It would be very useful, yes. Alternatively, you could extend the initrd format to have a firmware directory appended after the filesystem image. ACPI is going to abuse the initrd in just that way to override ACPI tables very soon (patches have been already submitted to linux-acpi), so if a more structured and extensible way to piggy-back early-init data in the initrd is needed, it would be good to bring that to the table NOW. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
On Tue, 30 Aug 2011, Borislav Petkov wrote: On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 29 Aug 2011, Borislav Petkov wrote: So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and parse_setup_data() can look at them and map them somewhere later for the driver to find. This should be doable because you're only gonna need a handful of blobs for CPU ucode, network and GPU if the last is compiled in. I wanted to take a serious look at that for the ucode loading, maybe I should try to shuffle some time for it... It would be very useful, yes. Alternatively, you could extend the initrd format to have a firmware directory appended after the filesystem image. ACPI is going to abuse the initrd in just that way to override ACPI tables very soon (patches have been already submitted to linux-acpi), .. lemme guess: they didn't put the correct tables in the BIOS in the first place and now it is too late for a BIOS fix and want to shuffle in all those fixes through initrd ontop of ACPI. Oh boy, do I love all the ACPI crap stories :). Heh. Actually, the patches were created by a distro for debug purposes. No vendor pushed for them. But it is a safe bet that users will end up using them to work around ACPI vendor crap that will never get fixed properly through a BIOS update, etc. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
On Tue, 30 Aug 2011, Peter Zijlstra wrote: On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote: On Mon, 29 Aug 2011, Borislav Petkov wrote: So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and parse_setup_data() can look at them and map them somewhere later for the driver to find. This should be doable because you're only gonna need a handful of blobs for CPU ucode, network and GPU if the last is compiled in. I wanted to take a serious look at that for the ucode loading, maybe I should try to shuffle some time for it... It would be very useful, yes. Alternatively, you could extend the initrd format to have a firmware directory appended after the filesystem image. ACPI is going to abuse the initrd in just that way to override ACPI tables very soon (patches have been already submitted to linux-acpi), so if a more structured and extensible way to piggy-back early-init data in the initrd is needed, it would be good to bring that to the table NOW. Uhm,.. does that mean that soon we can't boot kernels without initrd? That too is a massive regression in my eyes. Well, if work starts soon enough on a bootloader extension to avoid messing with the initrd, we could refuse to set that initrd-based ACPI table override as ABI on the grounds that it is a debug thing, and later move it to the properly designed firmware bootloader extension. Maybe the grub multiboot protocol[1] is worth looking at, assuming that thing is salvagable and would actually work for both 32bit and 64bit BIOS and UEFI bootstrapping? [1]http://www.gnu.org/software/grub/manual/multiboot/multiboot.html -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
On Mon, 29 Aug 2011, Borislav Petkov wrote: So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and parse_setup_data() can look at them and map them somewhere later for the driver to find. This should be doable because you're only gonna need a handful of blobs for CPU ucode, network and GPU if the last is compiled in. I wanted to take a serious look at that for the ucode loading, maybe I should try to shuffle some time for it... It would be very useful, yes. Alternatively, you could extend the initrd format to have a firmware directory appended after the filesystem image. ACPI is going to abuse the initrd in just that way to override ACPI tables very soon (patches have been already submitted to linux-acpi), so if a more structured and extensible way to piggy-back early-init data in the initrd is needed, it would be good to bring that to the table NOW. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
