Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote: > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote: > > > Acked-by: Darren Hart (VMware) > > > > As for a longer term solution, would it be possible to init fops in such > > a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg > > so we don't have to duplicate this boilerplate for every ioctl fops > > structure? > > Bad idea, that... Because several years down the road somebody will add > an ioctl that takes an unsigned int for argument. Without so much as looking > at your magical mystery macro being used to initialize file_operations. Fair, being explicit in the declaration as it is currently may be preferable then. -- Darren Hart VMware Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Wed, Sep 12, 2018 at 05:08:52PM +0200, Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
> ---
...
> drivers/platform/x86/wmi.c | 2 +-
...
> static void link_event_work(struct work_struct *work)
> diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
> index 04791ea5d97b..e4d0697e07d6 100644
> --- a/drivers/platform/x86/wmi.c
> +++ b/drivers/platform/x86/wmi.c
> @@ -886,7 +886,7 @@ static const struct file_operations wmi_fops = {
> .read = wmi_char_read,
> .open = wmi_char_open,
> .unlocked_ioctl = wmi_ioctl,
> - .compat_ioctl = wmi_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
For platform/drivers/x86:
Acked-by: Darren Hart (VMware)
As for a longer term solution, would it be possible to init fops in such
a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg
so we don't have to duplicate this boilerplate for every ioctl fops
structure?
--
Darren Hart
VMware Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] apple-gmux: Sphinxify docs
On Tue, Jul 12, 2016 at 03:11:45PM +0200, Daniel Vetter wrote: > On Fri, Jul 08, 2016 at 07:49:32AM +0200, Lukas Wunner wrote: > > On Wed, Jul 06, 2016 at 01:40:25PM -0700, Darren Hart wrote: > > > On Mon, Jul 04, 2016 at 12:40:35PM +0200, Lukas Wunner wrote: > > > > Convert asciidoc-formatted docs to rst in accordance with Jonathan's and > > > > Jani's effort to use sphinx for kernel-doc rendering in 4.8. > > > > > > Somebody help me out here. How do I verify this works and using sphinx? > > > to build the docs? > > > > (1) git remote add l1k https://github.com/l1k/linux.git > > git fetch l1k > > git checkout l1k/sphinx-docs > > (Alternatively: git cherry-pick v4.7-rc6..l1k/sphinx-docs ) > > > > (2) sudo apt-get install python-sphinx python-sphinx-rtd-theme > > > > (3) make xmldocs > > make htmldocs > > > > (4) open Documentation/output/html/index.html > > click on "VGA Switcheroo", then click on "Handlers" in the > > navigation pane on the left > > > > The apple-gmux docs are currently asciidoc-formatted. Support for > > markdown/asciidoc in kerneldoc was an Intel-sponsored effort last year > > led by Daniel, but never got upstreamed. > > > > After some deliberation the decision was made to use rst instead. > > Support for it is in docs-next, i.e. will be in 4.8. > > > > Jani has converted the gpu docs to rst and deleted the gpu.tmpl, > > this is on the drm-intel/for-linux-next branch but not yet in drm-next. > > Jani and Daniel are both on vacation. Daniel has indicated that he > > considers sending another drm-intel-next pull when he returns next week, > > then the rst-formatted gpu docs would land in drm-next: > > https://lists.freedesktop.org/archives/intel-gfx/2016-June/099114.html > > > > > > > Should I be merging this directly, or is it dependent on something Jon > > > is working on and therefore to be merged by him? > > > > It is not dependent on someone else. You can either merge it directly > > through your tree or alternatively ack it and have it merged through > > drm-intel trees by Daniel (+ cc:) next week. > > > > > > Unfortunately there is currently no branch which contains all the rst > > patches in docs-next *and* the rst-formatted gpu docs in drm-intel. > > (Some patches in docs-next are missing from drm-intel/for-linux-next.) > > That's why I pushed the above-mentioned branch to my GitHub repo, > > it contains everything needed: > > https://github.com/l1k/linux/commits/sphinx-docs > > Probably best to pull this in through drm-misc, which contains docs-next > plus the skeleton conversion of the drm docs over to sphinx/rst. Darren, > ack on that? Acked-by: Darren Hart I've dropped this from my testing branch (I never pushed it to my next branch) and will leave it to you to pull in. > > Oh and if you want to take a peek at the pretty docs this gives us: > > https://01.org/linuxgraphics/gfx-docs/drm/ Very nice. > > This is just the drm part, but if you pull in docs-next there should be > even more. Media/tv might also be ready for 4.8. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > -- Darren Hart Intel Open Source Technology Center
[PATCH] apple-gmux: Sphinxify docs
I SN74LV4066A`_ which is controlled by gmux.
> * The inactive GPU can thus probe the panel's EDID without switching over
> * the entire panel. Retinas lack this functionality as the chips used for
> * eDP muxing are incapable of switching the AUX channel separately (see
> @@ -344,15 +338,15 @@ static const struct backlight_ops gmux_bl_ops = {
> *
> * The external DP port is only fully switchable on the first two unibody
> * MacBook Pro generations, MBP5 2008/09 and MBP6 2010. This is done by an
> - * {6}[NXP CBTL06141] which is controlled by gmux. It's the predecessor of
> the
> + * `NXP CBTL06141`_ which is controlled by gmux. It's the predecessor of the
> * eDP mux on retinas, the difference being support for 2.7 versus 5.4
> Gbit/s.
> *
> * The following MacBook Pro generations replaced the external DP port with a
> * combined DP/Thunderbolt port and lost the ability to switch it between
> GPUs,
> * connecting it either to the discrete GPU or the Thunderbolt controller.
> * Oddly enough, while the full port is no longer switchable, AUX and HPD
> - * are still switchable by way of an {10}[NXP CBTL03062] (on pre-retinas
> - * MBP8 2011 and MBP9 2012) or two {11}[TI TS3DS10224] (on retinas) under the
> + * are still switchable by way of an `NXP CBTL03062`_ (on pre-retinas
> + * MBP8 2011 and MBP9 2012) or two `TI TS3DS10224`_ (on retinas) under the
> * control of gmux. Since the integrated GPU is missing the main link,
> * external displays appear to it as phantoms which fail to link-train.
> *
> @@ -365,10 +359,19 @@ static const struct backlight_ops gmux_bl_ops = {
> * of this feature.
> *
> * gmux' initial switch state on bootup is user configurable via the EFI
> - * variable `gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9` (5th byte,
> + * variable ``gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9`` (5th
> byte,
> * 1 = IGD, 0 = DIS). Based on this setting, the EFI firmware tells gmux to
> * switch the panel and the external DP connector and allocates a framebuffer
> * for the selected GPU.
> + *
> + * .. _US 8,687,007 B2: http://pimg-fpiw.uspto.gov/fdd/07/870/086/0.pdf
> + * .. _NXP CBTL06141: http://www.nxp.com/documents/data_sheet/CBTL06141.pdf
> + * .. _NXP CBTL06142: http://www.nxp.com/documents/data_sheet/CBTL06141.pdf
> + * .. _TI HD3SS212: http://www.ti.com/lit/ds/symlink/hd3ss212.pdf
> + * .. _Pericom PI3VDP12412:
> https://www.pericom.com/assets/Datasheets/PI3VDP12412.pdf
> + * .. _TI SN74LV4066A: http://www.ti.com/lit/ds/symlink/sn74lv4066a.pdf
> + * .. _NXP CBTL03062:
> http://pdf.datasheetarchive.com/indexerfiles/Datasheets-SW16/DSASW00308511.pdf
> + * .. _TI TS3DS10224: http://www.ti.com/lit/ds/symlink/ts3ds10224.pdf
> */
>
> static void gmux_read_switch_state(struct apple_gmux_data *gmux_data)
> --
> 2.8.1
>
>
--
Darren Hart
Intel Open Source Technology Center
[PATCH v5 00/12] Enable GPU switching on pre-retina MacBook Pro
On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote: > Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5. > > The main obstacle on these machines is that the panel mode in VBIOS > is bogus. Fortunately gmux can switch DDC independently from the > display, thereby allowing the inactive GPU to probe the panel's EDID. > > In short, vga_switcheroo and apple-gmux are amended with hooks to > switch DDC, DRM core is amended with a drm_get_edid_switcheroo() helper, > and relevant drivers are amended to call that for LVDS outputs. > > The retina MacBook Pro (2012 - present) uses eDP and cannot switch > AUX independently from the main link. The main obstacle there is link > training, I'm currently working on this, it will be addressed in a > future patch set. > > This series is also reviewable on GitHub: > https://github.com/l1k/linux/commits/mbp_switcheroo_v5 > > Changes: > > * New patch [01/12]: vga_switcheroo handler flags > Alex Deucher asked if this series might regress on non-Apple laptops. > To address this concern, I let handlers declare their capabilities in > a bitmask. DRM drivers call drm_get_edid_switcheroo() only if the > handler has set the VGA_SWITCHEROO_CAN_SWITCH_DDC flag. > Currently just one other flag is defined which is used on retinas. > > * Changed patch [02/12]: vga_switcheroo DDC locking > Rename ddc_lock to mux_hw_lock, suggested by Daniel Vetter. > > * New patch [03/12]: track switch state of apple-gmux > Fixes a bug in previous versions of this series which occurred if > the system was suspended while DDC was temporarily switched: > On resume DDC was switched to the wrong GPU. > > * New patches [09/12 - 12/12]: deferred probing > Previously I used connector reprobing if the inactive GPU's driver > loaded before gmux. I've ditched that in favor of deferred driver > probing, which is much simpler. Thanks to Daniel Vetter for the > suggestion. > > Caution: Patch [09/12] depends on a new acpi_dev_present() API which > will land in 4.5 via Rafael J. Wysocki's tree. > > I would particularly be interested in feedback on the handler flags > patch [01/12]. I'm not 100% happy with the number of characters > required to query the flags (e.g.: if (vga_switcheroo_handler_flags() & > VGA_SWITCHEROO_CAN_SWITCH_DDC)), but failed to come up with something > shorter. Thierry Reding used a struct of bools instead of a bitmask > for his recent drm_dp_link_caps patches. Maybe use that instead? > http://lists.freedesktop.org/archives/dri-devel/2015-December/097025.html No objection from the platform-driver-x86 side. I can pull these separately once the core is in, or these can be included with that core (preferred) with my Reviewed-by for 1, 3, 4, and 9. Reviewed-by: Darren Hart -- Darren Hart Intel Open Source Technology Center
[PATCH v2 0/1] apple-gmux: Add initial documentation
On Mon, Jan 11, 2016 at 08:19:54PM +0100, Lukas Wunner wrote: > Hi Darren, > > On Mon, Jan 11, 2016 at 09:45:25AM -0800, Darren Hart wrote: > > On Mon, Jan 11, 2016 at 08:03:18AM +0100, Daniel Vetter wrote: > > > On Mon, Jan 11, 2016 at 12:08:35AM +0100, Lukas Wunner wrote: > > > > On Fri, Jan 08, 2016 at 09:49:22AM -0700, Jonathan Corbet wrote: > > > > > Well, it's built around the asciidoc patch, which isn't in the > > > > > mainline > > > > > at this point. Should things go a different direction, that could > > > > > force > > > > > some changes here; > > > > > > > > If/when that happens, I'll be happy to fixup the documentation as > > > > needed. > > > > In fact I originally wrote this in markdown in November, then converted > > > > it to asciidoc in December and that really wasn't a big deal. > > > > > > > > The need for asciidoc arises from the desire to not clutter up the prose > > > > text with URLs. To achieve this, asciidoc allows defining so-called > > > > "attribute entries" which may then be referenced in the text: > > > > http://asciidoc.org/userguide.html#X62 > > > > > > > > Markdown has a similar feature called "reference style links", the > > > > difference being that they can be defined anywhere in the document, > > > > whereas asciidoc's "attribute entries" must precede their usage in > > > > the text: > > > > https://daringfireball.net/projects/markdown/syntax#link > > > > > > > > > > > > Here's a v2, the only change is Bruno Pr?mont's addition to the commit > > > > message. > > > > > > > > @Daniel Vetter: Could you pick this up for topic/drm-misc please? > > > > > > I think it makes more sense to pull this in through Darren's tree, and I > > > acked that on the last round already. > > > > OK, I'm happy to take it. Lukas, this doesn't apply cleanly to my 4.4-rc* > > based > > for-next branch or Linus's 4.4 from yesterday. I can manually apply it: > > > > $ patch -p1 < > > ~/incoming/PATCH_v2_1-1_apple-gmux_Add_initial_documentation.mbox > > patching file Documentation/DocBook/gpu.tmpl > > Hunk #1 succeeded at 4279 with fuzz 1 (offset 809 lines). > > patching file drivers/platform/x86/apple-gmux.c > > > > But that is one hell of an offset. What are you developing against and can > > you > > send me something that applies cleanly? > > I'm developing against drm-next and/or drm-intel-nightly. > Looks like gpu.tmpl is touched very frequently. :-) > > As for the apple-gmux documentation, Daniel picked it up this afternoon: > http://cgit.freedesktop.org/drm-intel/commit/?h=topic/drm-misc=3d7b75fdae9c81dd71c7573dbc285af90e0924fa > > So, everything's fine. Thanks a lot though for being such a responsive > and speedy maintainer, much appreciated! > Hah, and here I am beating myself up over letting things stagnate. Thanks :-) -- Darren Hart Intel Open Source Technology Center
[PATCH v2 0/1] apple-gmux: Add initial documentation
On Mon, Jan 11, 2016 at 08:03:18AM +0100, Daniel Vetter wrote: > On Mon, Jan 11, 2016 at 12:08:35AM +0100, Lukas Wunner wrote: > > On Fri, Jan 08, 2016 at 09:49:22AM -0700, Jonathan Corbet wrote: > > > Well, it's built around the asciidoc patch, which isn't in the mainline > > > at this point. Should things go a different direction, that could force > > > some changes here; > > > > If/when that happens, I'll be happy to fixup the documentation as needed. > > In fact I originally wrote this in markdown in November, then converted > > it to asciidoc in December and that really wasn't a big deal. > > > > The need for asciidoc arises from the desire to not clutter up the prose > > text with URLs. To achieve this, asciidoc allows defining so-called > > "attribute entries" which may then be referenced in the text: > > http://asciidoc.org/userguide.html#X62 > > > > Markdown has a similar feature called "reference style links", the > > difference being that they can be defined anywhere in the document, > > whereas asciidoc's "attribute entries" must precede their usage in > > the text: > > https://daringfireball.net/projects/markdown/syntax#link > > > > > > Here's a v2, the only change is Bruno Pr?mont's addition to the commit > > message. > > > > @Daniel Vetter: Could you pick this up for topic/drm-misc please? > > I think it makes more sense to pull this in through Darren's tree, and I > acked that on the last round already. OK, I'm happy to take it. Lukas, this doesn't apply cleanly to my 4.4-rc* based for-next branch or Linus's 4.4 from yesterday. I can manually apply it: $ patch -p1 < ~/incoming/PATCH_v2_1-1_apple-gmux_Add_initial_documentation.mbox patching file Documentation/DocBook/gpu.tmpl Hunk #1 succeeded at 4279 with fuzz 1 (offset 809 lines). patching file drivers/platform/x86/apple-gmux.c But that is one hell of an offset. What are you developing against and can you send me something that applies cleanly? -- Darren Hart Intel Open Source Technology Center
[PATCH 0/1] apple-gmux: Add initial documentation
On Mon, Jan 04, 2016 at 05:52:06PM +0100, Lukas Wunner wrote: > Initial documentation for apple-gmux. If anyone has additions or > corrections please let me know. > > This uses asciidoc markup, an HTML rendered version is available here: > http://wunner.de/gpu_docs/handlers.html > > If you prefer perusing the patch in a browser: > https://github.com/l1k/linux/commit/68eb066089346b4ba9aefdcbc69e66524427515e > > @Darren Hart: > Barring any objections, please kindly provide an ack for merging via > drm-next or drm-intel as I will post a new iteration of my GPU switching > patches shortly which are based on this patch and which should also go in > via drm-next/drm-intel. Thank you! Eek, apologies for my previous email, I missed the cover letter and reviewed 1/1 independently. For platform/drivers/x86: Acked-by: Darren Hart > > > Lukas Wunner (1): > apple-gmux: Add initial documentation > > Documentation/DocBook/gpu.tmpl| 22 > drivers/platform/x86/apple-gmux.c | 113 > ++ > 2 files changed, 135 insertions(+) > > -- > 1.8.5.2 (Apple Git-48) > > -- Darren Hart Intel Open Source Technology Center
[PATCH 1/1] apple-gmux: Add initial documentation
l to link-train.
> + *
> + * gmux receives the HPD signal of all display connectors and sends an
> + * interrupt on hotplug. On generations which cannot switch external ports,
> + * the discrete GPU can then be woken to drive the newly connected display.
> + * The ability to switch AUX on these generations could be used to improve
> + * reliability of hotplug detection by having the integrated GPU poll the
> + * ports while the discrete GPU is asleep, but currently we do not make use
> + * of this feature.
> + *
> + * gmux' initial switch state on bootup is user configurable via the EFI
> + * variable `gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9` (5th byte,
> + * 1 = IGD, 0 = DIS). Based on this setting, the EFI firmware tells gmux to
> + * switch the panel and the external DP connector and allocates a framebuffer
> + * for the selected GPU.
> + */
> +
> static int gmux_switchto(enum vga_switcheroo_client_id id)
> {
> if (id == VGA_SWITCHEROO_IGD) {
> @@ -288,6 +383,14 @@ static int gmux_switchto(enum vga_switcheroo_client_id
> id)
> return 0;
> }
>
> +/**
> + * DOC: Power control
> + *
> + * gmux is able to cut power to the discrete GPU. It automatically takes care
> + * of the correct sequence to tear down and bring up the power rails for
> + * core voltage, VRAM and PCIe.
> + */
> +
> static int gmux_set_discrete_state(struct apple_gmux_data *gmux_data,
> enum vga_switcheroo_state state)
> {
> @@ -352,6 +455,16 @@ static const struct vga_switcheroo_handler gmux_handler
> = {
> .get_client_id = gmux_get_client_id,
> };
>
> +/**
> + * DOC: Interrupt
> + *
> + * gmux is also connected to a GPIO pin of the southbridge and thereby is
> able
> + * to trigger an ACPI GPE. On the MBP5 2008/09 it's GPIO pin 22 of the Nvidia
> + * MCP79, on all following generations it's GPIO pin 6 of the Intel PCH.
> + * The GPE merely signals that an interrupt occurred, the actual type of
> event
> + * is identified by reading a gmux register.
> + */
> +
> static inline void gmux_disable_interrupts(struct apple_gmux_data *gmux_data)
> {
> gmux_write8(gmux_data, GMUX_PORT_INTERRUPT_ENABLE,
> --
> 1.8.5.2 (Apple Git-48)
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> platform-driver-x86" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Darren Hart
Intel Open Source Technology Center
[PATCH 1/1] apple-gmux: Assign apple_gmux_data before registering
On Mon, Nov 16, 2015 at 09:38:40PM +0100, Lukas Wunner wrote: > From: Matthew Garrett > > Registering the handler after both GPUs will trigger a DDC switch for > connector reprobing. This will oops if apple_gmux_data hasn't already > been assigned. Reorder the code to do that. > > [Lukas: More generally, this commit fixes a race condition that > is triggered by invoking a handler callback between the call to > vga_switcheroo_register_handler() and the assignment of > apple_gmux_data.] > > Tested-by: Pierre Moreau > [MBP 5,3 2009 nvidia MCP79 + G96pre-retina 15"] > Tested-by: Paul Hordiienko > [MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina 15"] > Tested-by: Lukas Wunner > [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"] > Tested-by: William Brown > [MBP 8,2 2011 intel SNB + amd turks pre-retina 15"] > Tested-by: Bruno Bierbaumer > [MBP 11,3 2013 intel HSW + nvidia GK107 retina 15"] > > Signed-off-by: Matthew Garrett > Reviewed-by: Lukas Wunner > Signed-off-by: Lukas Wunner My apologies for the delay. Thank you for the testing data and submitting. I have queued this to testing. Pending success on 0-day, it will land in linux-next shortly (tomorrow most likely) where I hope it will receive additional testing. -- Darren Hart Intel Open Source Technology Center
[PATCH 0/1] apple-gmux: Assign apple_gmux_data before registering
Hi Lukas, Please send the patch to the list and maintainers reported by get_maintainer.pl (specifically the platform-driver-x86 list and my infradead ID) so we can have the review on list. Thanks, On 11/9/15 11:28 AM, Lukas Wunner wrote: > Hi Darren, > > the following patch is a useful fix for apple-gmux by Matthew Garrett > which is well over a year old but unfortunately never got merged. > > The commit message makes it sound as if the fix is only needed for > reprobing (in case apple-gmux registers after the DRM drivers). > I'm not yet sure if we'll use reprobing or deferred initialization, > however the patch is needed even if we go with deferred initialization > as it fixes a race condition that is triggered by invoking a handler > callback between the call to vga_switcheroo_register_handler() and the > assignment of apple_gmux_data. > > The patch has seen extensive testing and is actively used by myself > and others on various MacBook Pro models. > > Could you take a look at the patch and (barring any objections) ack it? > > Thanks, > > Lukas > > > Matthew Garrett (1): > apple-gmux: Assign apple_gmux_data before registering > > drivers/platform/x86/apple-gmux.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > -- Darren Hart Intel Open Source Technology Center
[PATCH v4 2/6] apple-gmux: Add switch_ddc support
On Fri, Aug 14, 2015 at 06:18:55PM +0200, Lukas Wunner wrote: > Originally by Seth Forshee , 2012-10-04: > The gmux allows muxing the DDC independently from the display, so > support this functionality. This will allow reading the EDID for the > inactive GPU, fixing issues with machines that either don't have a > VBT or have invalid mode data in the VBT. > > Modified by Lukas Wunner , 2015-10-07: > Advertise ->switch_ddc handler callback only on the pre-retina > Macbook Pro. The retina uses eDP and its mux is incapable of > switching the AUX channel separately from the main link. > It's an NXP CBTL06142 (alternate parts: TI HD3SS212, > Pericom PPI3VDP12412). > > Sources: > http://www.electronicproducts.com/-whatsinside_text-145.aspx > > http://slideshare.net/jjwu6266/apple-2012-wwdc-apple-macbook-pro-with-retina-display > > http://www.techrepublic.com/blog/cracking-open/teardown-shows-retina-macbook-pro-is-nearly-impossible-to-upgrade-difficult-to-work-on/ > > Datasheets: > http://www.nxp.com/documents/data_sheet/CBTL06141.pdf > http://www.ti.com/lit/ds/symlink/hd3ss212.pdf > https://www.pericom.com/assets/Datasheets/PI3VDP12412.pdf > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115 > Tested-by: Lukas Wunner > [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"] > > Cc: Seth Forshee > Signed-off-by: Lukas Wunner For platform/drivers/x86: Acked-by: Darren Hart Daniel, I presume this will ultimately get pulled in by you with the rest of the series? -- Darren Hart Intel Open Source Technology Center
v4.3-rc4: i915: ThinkPad Yoga 12: *ERROR* The master control interrupt lied (SDE)!
On Mon, Oct 12, 2015 at 10:02:06AM +0300, Jani Nikula wrote: > On Sat, 10 Oct 2015, Darren Hart wrote: > > The Debian 3.16.0 kernel does not emit the error, but I have not attempted a > > bisection. > > > > The warning was added by: > > 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8) > > 2014-06-18 (1 year, 4 months ago), Oscar Mateo > > But we don't start hitting the warning right away with that commit, do > we? There's a bug about this with a bisected bad commit [1], please > let's track this there. I did a google search and didn't find any relevant hits for this error. So I reported it here. I should ahve searched the bug list also. I'll do that next time. -- Darren Hart Intel Open Source Technology Center
v4.3-rc4: i915: ThinkPad Yoga 12: *ERROR* The master control interrupt lied (SDE)!
The Debian 3.16.0 kernel does not emit the error, but I have not attempted a bisection. The warning was added by: 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8) 2014-06-18 (1 year, 4 months ago), Oscar Mateo Follows: v3.15-rc8 Preceedes: 3.17-rc1 This is not present in v3.16, so perhaps not present in the Debian kernel and this is not a regression, but just reporting the condition as intended. Linux Version: v4.3-rc4 Platform: Lenovo ThinkPad Yoga 12 OS: Debian 8.2 $ dmesg | grep -i drm [ 10.918367] [drm] Initialized drm 1.1.0 20060810 [ 11.235005] [drm] Memory usable by graphics device = 4096M [ 11.235009] fb: switching to inteldrmfb from simple [ 11.235093] [drm] Replacing VGA console driver [ 11.241160] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 11.241162] [drm] Driver supports precise vblank timestamp query. [ 11.256249] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0! [ 11.326946] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [ 11.344097] [drm] Initialized i915 1.6.0 20150731 for :00:02.0 on minor 0 [ 11.344913] fbcon: inteldrmfb (fb0) is primary device [ 12.462509] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 12.466498] i915 :00:02.0: fb0: inteldrmfb frame buffer device [ 12.794359] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 13.869733] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 13.869894] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 13.870058] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 22.656986] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 257.506246] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 257.506415] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 257.506584] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 257.506746] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 278.722570] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 278.722744] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 278.722908] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 1857.776390] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 1857.776549] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 1857.776710] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 4057.592685] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! -- Darren Hart Intel Open Source Technology Center
[PATCH v2 00/32] acpi-video: Rewrite backlight interface selection logic
On Wed, Jun 17, 2015 at 11:36:13AM +0200, Rafael J. Wysocki wrote: > On Wed, Jun 17, 2015 at 5:39 AM, Darren Hart wrote: > > On Tue, Jun 16, 2015 at 01:22:40AM +0200, Rafael Wysocki wrote: > >> On Friday, June 12, 2015 01:23:19 PM Hans de Goede wrote: > >> > Hi All, > >> > > >> > Here is v2 of my rewrite / cleanup of the acpi-video (and platform/x86) > >> > backlight interface selection logic. > >> > > >> > The major change in v2 of this set are 2 changes to the patch titled > >> > "acpi-video-detect: video: Make video_detect code part of the video > >> > module": > >> > > >> > 1) The __setup call for the acpi_backlight= handling is moved to > >> >acpi/util.c as __setup may only be used by code which is always > >> > builtin > >> > 2) video.c is renamed to acpi_video.c so that it can be combined with > >> >video_detect.c into video.ko > >> > > >> > These 2 changes result in the backlight kernel commandline options after > >> > this > >> > patch-set being 100% compatible with the old options, with the exception > >> > of > >> > the removal of the video.use_native_backlight option as that now is > >> > folded > >> > into acpi_backlight=[video|vendor|native|none] rather then having 2 > >> > options > >> > which influence each other in interesting ways. > >> > > >> > Besides that there is a small change to the dell-laptop port to the new > >> > API > >> > removing an unnecessary #ifdef ACPI. > >> > >> I tried to queue this series up for 4.2, but patch [06/32] didn't apply > >> for me, > >> so I decided to apply another patch I've got recently instead and which is > >> now > >> in my linux-next branch. > >> > >> Can you please rebase the series on top of linux-pm.git/linux-next and > >> resend it? > > > > Rafael, do you intent to carry this entire series and submit via linux-pm? > > Yes, I do. In that case, Acked-by: Darren Hart For the platform/drivers/x86 patches. -- Darren Hart Intel Open Source Technology Center
[PATCH v2 00/32] acpi-video: Rewrite backlight interface selection logic
On Tue, Jun 16, 2015 at 01:22:40AM +0200, Rafael Wysocki wrote: > On Friday, June 12, 2015 01:23:19 PM Hans de Goede wrote: > > Hi All, > > > > Here is v2 of my rewrite / cleanup of the acpi-video (and platform/x86) > > backlight interface selection logic. > > > > The major change in v2 of this set are 2 changes to the patch titled > > "acpi-video-detect: video: Make video_detect code part of the video module": > > > > 1) The __setup call for the acpi_backlight= handling is moved to > >acpi/util.c as __setup may only be used by code which is always builtin > > 2) video.c is renamed to acpi_video.c so that it can be combined with > >video_detect.c into video.ko > > > > These 2 changes result in the backlight kernel commandline options after > > this > > patch-set being 100% compatible with the old options, with the exception of > > the removal of the video.use_native_backlight option as that now is folded > > into acpi_backlight=[video|vendor|native|none] rather then having 2 options > > which influence each other in interesting ways. > > > > Besides that there is a small change to the dell-laptop port to the new API > > removing an unnecessary #ifdef ACPI. > > I tried to queue this series up for 4.2, but patch [06/32] didn't apply for > me, > so I decided to apply another patch I've got recently instead and which is now > in my linux-next branch. > > Can you please rebase the series on top of linux-pm.git/linux-next and resend > it? Rafael, do you intent to carry this entire series and submit via linux-pm? -- Darren Hart Intel Open Source Technology Center
[PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers
On Mon, Jun 01, 2015 at 11:25:05AM +0200, Hans de Goede wrote: > Hi All, > > I'm working on cleaning up the currently somewhat convoluted logic to > select which backlight interfaces to register on x86 systems, see: > http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html > > For a rought outline (details will change in the actual patch-set). > > These 3 patches are a preparation for that work, as the behavior of the > current code is not always consistent (it changes depending on module > loading order in some cases). These 3 patches remove this inconsistency > which in some cases may result in a behavior change. > > This way the cleanup can have a consistent base to build upon, and I can > ensure that the cleanup itself does not cause any functional changes. These are now available in for-next. -- Darren Hart Intel Open Source Technology Center
[PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers
On Mon, Jun 01, 2015 at 11:25:05AM +0200, Hans de Goede wrote: > Hi All, > > I'm working on cleaning up the currently somewhat convoluted logic to > select which backlight interfaces to register on x86 systems, see: > http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html > > For a rought outline (details will change in the actual patch-set). > > These 3 patches are a preparation for that work, as the behavior of the > current code is not always consistent (it changes depending on module > loading order in some cases). These 3 patches remove this inconsistency > which in some cases may result in a behavior change. > > This way the cleanup can have a consistent base to build upon, and I can > ensure that the cleanup itself does not cause any functional changes. > > I hope to post a v1 of the actual cleanup patch-set in 1-2 weeks. Letting these sit in my testing branch while awaiting at ack from Corentin on 2 of the 3. -- Darren Hart Intel Open Source Technology Center
[PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers
On Mon, Jun 01, 2015 at 11:25:05AM +0200, Hans de Goede wrote: > Hi All, > > I'm working on cleaning up the currently somewhat convoluted logic to > select which backlight interfaces to register on x86 systems, see: > http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html > > For a rought outline (details will change in the actual patch-set). > > These 3 patches are a preparation for that work, as the behavior of the > current code is not always consistent (it changes depending on module > loading order in some cases). These 3 patches remove this inconsistency > which in some cases may result in a behavior change. > > This way the cleanup can have a consistent base to build upon, and I can > ensure that the cleanup itself does not cause any functional changes. > > I hope to post a v1 of the actual cleanup patch-set in 1-2 weeks. That will likely mean we miss the 4.2 merge window and will target this for 4.3 (which is fine by me, but just so you know). -- Darren Hart Intel Open Source Technology Center
My minnow was broken by: drm/i915: Consolidate forcewake code
+Jani Jani, I think this may have inadvertently undone the fix you made for us on the MinnowMax. On Fri, Jan 23, 2015 at 1:44 PM, Olof Johansson wrote: > Hi Daniel, Mika, > > For the first time in a few days, -next was bootable last night. I > noticed that my Minnowboard Max didn't actually boot though, it got > stuck shortly after or during DRM probing: > > http://arm-soc.lixom.net/bootlogs/next/next-20150123/minnowmax-x86-minnowmax_defconfig.html > > I bisected it down to the below patch that I failed to find posted > (with that subject) anywhere on a public list that I am subscribed to. > > The patch isn't revertable without considerable effort so I can't > double check that it's just this one change, but the commit before > that in the branch boots, this one does not. > > > commit fc72355f5c04c40f2916a07e9f8d4b357e2e0a93 > Author: Mika Kuoppala > AuthorDate: Mon Jan 19 16:20:43 2015 +0200 > Commit: Daniel Vetter > CommitDate: Tue Jan 20 12:36:57 2015 +0100 > > drm/i915: Consolidate forcewake code > > As we now have forcewake domains, take advantage of it > by putting the differences in gen fw handling in data rather > than in code. > > In past we have opencoded this quite extensively as the fw handling > is in the fast path. There has also been a lot of cargo-culted > copy'n'pasting from older gens to newer ones. > > Now when the releasing of the forcewake is done by deferred timer, > it gives chance to consolidate more. Due to the frequency of actual hw > access being significantly less. > > Take advantage of this and generalize the fw handling code > as much as possible. But we still aim to keep the forcewake sequence > particularities for each gen intact. So the access pattern > to fw engines should remain the same. > > v2: - s/old_ack/clear_ack (Chris) > - s/post_read/posting_read (Chris) > - less polite commit msg (Chris) > > v3: - rebase > - check and clear wake_count in init > > v4: - fix posting reads for gen8 (PRTS) > > Signed-off-by: Mika Kuoppala > Reviewed-by: Deepak S (v2) > Signed-off-by: Daniel Vetter -- Darren Hart
[PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On Sat, Oct 18, 2014 at 12:13:23AM +0300, Jani Nikula wrote: > Documentation/kbuild/kconfig-language.txt warns to use select with care, > and in general use select only for non-visible symbols and for symbols > with no dependencies, because select will force a symbol to a value > without visiting the dependencies. > > Select has become particularly problematic, interdependently, with the > BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO configs. For example: > > scripts/kconfig/conf --randconfig Kconfig > KCONFIG_SEED=0x48312B00 > warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 && > DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY > && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && > EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE > which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) > warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 && > DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY > && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && > EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE > which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) > > With tristates it's possible to end up selecting FOO=y depending on > BAR=m in the config, which gets discovered at build time, not config > time, like reported in the thread referenced below. > > Do the following to fix the dependencies: > > * Depend on instead of select BACKLIGHT_CLASS_DEVICE everywhere. Drop > select BACKLIGHT_LCD_SUPPORT in such cases, as it's a dependency of > BACKLIGHT_CLASS_DEVICE. > > * Remove config FB_BACKLIGHT altogether, and replace it with a > dependency on BACKLIGHT_CLASS_DEVICE. All configs selecting > FB_BACKLIGHT select or depend on FB anyway, so we can simplify. > > * Depend on (ACPI && ACPI_VIDEO) || ACPI=n in several places instead of > selecting ACPI_VIDEO and a number of its dependencies if ACPI is > enabled. This is tied to backlight, as ACPI_VIDEO depends on > BACKLIGHT_CLASS_DEVICE. > > * Replace a couple of select INPUT/VT with depends as it seemed to be > necessary. > > Reference: > http://lkml.kernel.org/r/CA+r1ZhhmT4DrWtf6MbRQo5EqXwx+LxCqh15Vsu_d9WpftLhnxw > at mail.gmail.com > Reported-by: Jim Davis > Cc: Randy Dunlap > Cc: David Airlie > Cc: Daniel Vetter > Cc: Greg Kroah-Hartman > Cc: Darren Hart > Cc: Laurent Pinchart > Cc: Benjamin Herrenschmidt > Cc: Jens Frederich > Cc: Daniel Drake > Cc: Jon Nettleton > Cc: Jean-Christophe Plagniol-Villard > Cc: Tomi Valkeinen > Signed-off-by: Jani Nikula As for the drivers/platform/x86/Kconfig: Acked-by: Darren Hart Thanks, -- Darren Hart Intel Open Source Technology Center
