On Wed, Oct 23, 2019 at 12:12:29PM +, Nicholas Johnson wrote:
> Add kernel parameter pci=hpmmiosize=nn[KMG] to set MMIO bridge window
> size for hotplug bridges.
>
> Add kernel parameter pci=hpmmioprefsize=nn[KMG] to set MMIO_PREF bridge
> window size for hotplug bridges.
>
> Leave pci=hpmems
On Wed, Oct 23, 2019 at 10:33:42AM +, Nicholas Johnson wrote:
> On Wed, Oct 23, 2019 at 01:03:59PM +0300, mika.westerb...@linux.intel.com
> wrote:
> > On Wed, Oct 23, 2019 at 09:57:17AM +, Nicholas Johnson wrote:
> > > On Wed, Oct 23, 2019 at 12:47:43P
On Wed, Oct 23, 2019 at 09:57:17AM +, Nicholas Johnson wrote:
> On Wed, Oct 23, 2019 at 12:47:43PM +0300, mika.westerb...@linux.intel.com
> wrote:
> > On Wed, Oct 23, 2019 at 08:37:48AM +, Nicholas Johnson wrote:
> > > } else if (!strncmp(
On Wed, Oct 23, 2019 at 08:37:48AM +, Nicholas Johnson wrote:
> } else if (!strncmp(str, "hpmemsize=", 10)) {
> - pci_hotplug_mem_size = memparse(str + 10, &str);
> + pci_hotplug_mmio_size =
> +
On Wed, Oct 23, 2019 at 08:36:59AM +, Nicholas Johnson wrote:
> This patch adds support for two new kernel parameters. This patch has
> been in the making for quite some time, and has changed several times
> based on feedback.
>
> I realised I was making the mistake of putting it as part of my
On Wed, Oct 23, 2019 at 09:16:10AM +, Nicholas Johnson wrote:
> On Tue, Oct 08, 2019 at 03:09:07PM +0300, mika.westerb...@linux.intel.com
> wrote:
> > On Fri, Jul 26, 2019 at 12:54:22PM +, Nicholas Johnson wrote:
> > > Remove checks for resource size in extend_bri
On Fri, Jul 26, 2019 at 12:55:03PM +, Nicholas Johnson wrote:
> Background
> ==
I don't think the above are needed.
> Currently, the kernel can sometimes assign the MMIO_PREF window
> additional size into the MMIO window,
On Fri, Jul 26, 2019 at 12:54:44PM +, Nicholas Johnson wrote:
> Add kernel parameter pci=hpmmiosize=nn[KMG] to set MMIO bridge window
> size for hotplug bridges.
>
> Add kernel parameter pci=hpmmioprefsize=nn[KMG] to set MMIO_PREF bridge
> window size for hotplug bridges.
>
> Leave pci=hpmems
On Fri, Jul 26, 2019 at 12:54:22PM +, Nicholas Johnson wrote:
> Remove checks for resource size in extend_bridge_window(). This is
> necessary to allow the pci_bus_distribute_available_resources() to
> function when the kernel parameter pci=hpmemsize=nn[KMG] is used to
> allocate resources. Bec
On Fri, Jul 26, 2019 at 12:54:01PM +, Nicholas Johnson wrote:
> Change extend_bridge_window() to set resource size directly instead of
> using additional resource lists.
>
> Because additional resource lists are optional resources, any algorithm
> that requires guaranteed allocation that uses
On Fri, Jul 26, 2019 at 12:53:41PM +, Nicholas Johnson wrote:
> In extend_bridge_window() change "available" parameter name to new_size.
> This makes more sense as this parameter represents the new size for the
> window.
>
> Signed-off-by: Nicholas Johnson
Reviewed-by: Mika Westerberg
Hi Nicholas,
On Fri, Jul 26, 2019 at 12:53:19PM +, Nicholas Johnson wrote:
> Rewrite pci_bus_distribute_available_resources to better handle bridges
> with different resource alignment requirements. Pass more details
> arguments recursively to track the resource start and end addresses
> relat
On Fri, Oct 04, 2019 at 08:08:03AM -0500, Bjorn Helgaas wrote:
> On Thu, Oct 03, 2019 at 03:19:46PM +0300, mika.westerb...@linux.intel.com
> wrote:
> > On Fri, Jul 26, 2019 at 12:52:58PM +, Nicholas Johnson wrote:
> > > Patch series rebased to 5.3-rc1.
> > >
&g
On Fri, Jul 26, 2019 at 12:52:58PM +, Nicholas Johnson wrote:
> Patch series rebased to 5.3-rc1.
>
> If possible, please have a quick read over while I am away (2019-07-27
> to mid 2019-08-04), so I can fix any mistakes or make simple changes to
> get problems out of the way for a more thoroug
On Wed, May 22, 2019 at 02:30:44PM +, Nicholas Johnson wrote:
> Rewrite pci_bus_distribute_available_resources to better handle bridges
> with different resource alignment requirements. Pass more details
> arguments recursively to track the resource start and end addresses
> relative to the ini
On Sat, Jun 15, 2019 at 02:56:36PM -0500, Bjorn Helgaas wrote:
> Mika, this patch changes code you added in 1a5767725cec ("PCI:
> Distribute available resources to hotplug-capable bridges"). Is there
> any chance you could help review this?
Sure, I'll take a look and comment separately.
> On Wed
Hi,
Please indicate in the $subject that this is second version of the
patch as explained in:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#the-canonical-patch-format
For example here the $subject should look like
[PATCH v2] PCI: Consider alignment of hot-added bri
Hi Nicholas,
On Thu, Jan 31, 2019 at 09:51:05AM +, Nicholas Johnson wrote:
> New systems with Thunderbolt are starting to use native PCI enumeration.
> Mika Westerberg's patch "PCI: Distribute available resources to hotplug
> capable PCIe downstream ports"
> (https://patchwork.kernel.org/patch
On Wed, Nov 14, 2018 at 02:30:14PM +0100, Lukas Wunner wrote:
> On Wed, Nov 14, 2018 at 11:52:25AM +0200, mika.westerb...@linux.intel.com
> wrote:
> > On Tue, Nov 13, 2018 at 03:57:47PM +, Shameerali Kolothum Thodi wrote:
> > > > The smb_mb() thing is not that clear
On Tue, Nov 13, 2018 at 03:57:47PM +, Shameerali Kolothum Thodi wrote:
> > The smb_mb() thing is not that clear (at least to me) because it is used
> > in two places in the driver and both seem to be making write to
> > ctrl->cmd_busy visible to other CPUs but I don't see where we deal with
> >
On Tue, Nov 13, 2018 at 01:28:04PM +, Shameerali Kolothum Thodi wrote:
>
> > -Original Message-
> > From: mika.westerb...@linux.intel.com
> > [mailto:mika.westerb...@linux.intel.com]
> > Sent: 13 November 2018 12:59
> > To: Shameerali Kolothum Thodi
On Tue, Nov 13, 2018 at 12:36:20PM +, Shameerali Kolothum Thodi wrote:
> > @@ -156,9 +156,9 @@ static void pcie_do_write_cmd(struct controller *ctrl,
> > u16 cmd,
> > slot_ctrl |= (cmd & mask);
> > ctrl->cmd_busy = 1;
> > smp_mb();
> > + ctrl->slot_ctrl = slot_ctrl;
>
> Actually
+Lukas
On Tue, Nov 13, 2018 at 11:45:42AM +, Shameerali Kolothum Thodi wrote:
> Hi Mika,
Hi,
> Since the commit commit 720d6a671a6e("PCI: pciehp: Do not handle events
> if interrupts are masked"), the hotplug support on Qemu Guest(4.120-rc1)
> with a vfio passthrough device seems to be broke
On Mon, Nov 27, 2017 at 04:21:34PM +, Bernat, Yehezkel wrote:
> On Mon, 2017-11-27 at 14:48 +0300, Mika Westerberg wrote:
> > When ring enters polling mode we are expected to mask the ring
> > interrupt
> > before the callback is called. However, the current code actually
> > unmasks it probabl
On Wed, Sep 13, 2017 at 10:11:21AM +0800, Bin Meng wrote:
> Hi Joakim,
>
> On Tue, Sep 12, 2017 at 1:44 AM, Joakim Tjernlund
> wrote:
> > On Mon, 2017-09-11 at 02:41 -0700, Bin Meng wrote:
> >> This series does several bug fixes and clean ups against the intel-spi
> >> spi-nor driver, as well as
On Thu, May 25, 2017 at 03:03:07PM +0300, mika.westerb...@linux.intel.com wrote:
> On Thu, May 25, 2017 at 11:04:08AM +0300, mika.westerb...@linux.intel.com
> wrote:
> > On Thu, May 25, 2017 at 10:20:10AM +0300, mika.westerb...@linux.intel.com
> > wrote:
> > > On Wed,
On Thu, May 25, 2017 at 11:04:08AM +0300, mika.westerb...@linux.intel.com wrote:
> On Thu, May 25, 2017 at 10:20:10AM +0300, mika.westerb...@linux.intel.com
> wrote:
> > On Wed, May 24, 2017 at 07:32:45PM +, Jamet, Michael wrote:
> > > I talked to our BIOS expert today.
On Thu, May 25, 2017 at 10:20:10AM +0300, mika.westerb...@linux.intel.com wrote:
> On Wed, May 24, 2017 at 07:32:45PM +, Jamet, Michael wrote:
> > I talked to our BIOS expert today. Here is his advice to debugging further:
> >
> > It looks like something may have been wr
On Wed, May 24, 2017 at 07:32:45PM +, Jamet, Michael wrote:
> I talked to our BIOS expert today. Here is his advice to debugging further:
>
> It looks like something may have been wrong from system (BIOS, FW, others...)
> perspective.
> On reboot need to enter EFI shell and check resources of
On Sat, May 20, 2017 at 09:15:17AM +, Levy, Amir (Jer) wrote:
> > I created a udev rule that will automatically authorize the dock and cable.
> > #dell cable
> > ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0",
> > ATTR{vendor}=="0xd4", ATTR{device}=="0xb051", ATTR{authorized}="1
On Fri, Oct 30, 2015 at 09:33:28AM -0700, Dmitry Torokhov wrote:
> cpi_dev_add_driver_gpios() does not really help with generic drivers
> (unless we keep adding more and more board specific data to them). How
> about we keep track of names used and only allow conversion for the
> first name used, l
On Mon, Oct 19, 2015 at 02:32:24PM +, Tirdea, Irina wrote:
>
>
> > -Original Message-
> > From: linux-input-ow...@vger.kernel.org
> > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of
> > mika.westerb...@linux.intel.com
> > Sent: 14 October
On Wed, Oct 14, 2015 at 02:18:20PM +0300, mika.westerb...@linux.intel.com wrote:
> On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote:
> > I understand why one might use acpi_dev_add_driver_gpios() to augment
> > data in ACPI, however here we have completely differen
On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote:
> I understand why one might use acpi_dev_add_driver_gpios() to augment
> data in ACPI, however here we have completely different issue: driver
> that expects named gpios gets returned gpio that has nothing to do with
> what it reques
On Tue, Oct 13, 2015 at 08:54:12AM +, Tirdea, Irina wrote:
> > > I did not use devm_gpiod_get_optional() in order to ignore more errors
> > > than -ENOENT. This is needed because the ACPI gpio core will fall back
> > > to indexed gpios if named gpios are not found. In the common case of
> > > h
On Wed, Jun 24, 2015 at 12:56:19PM +, De Marchi, Lucas wrote:
> Yeah, but it would be bad to ignore the problem as well. The way it is now
> kills any possibility of using DW controller for reading sensors like
> gyroscope, accelerometer, barometer that have higher sampling rate etc. I'll
> tr
On Fri, Feb 06, 2015 at 08:34:52AM +0800, Ken Xue wrote:
> >From 1a6a3a5c0815cb1f52ec0a2b9601edfa9bfebe81 Mon Sep 17 00:00:00 2001
> From: Ken Xue
> Date: Fri, 6 Feb 2015 08:27:51 +0800
> Subject: [PATCH] acpi:apd:add AMD ACPI2Platform device support for x86 system.
>
> This new feature is to int
On Thu, Feb 05, 2015 at 11:07:17AM +0800, Ken Xue wrote:
> >From d22789f089ee644413a144633f368f45cb0ac9d8 Mon Sep 17 00:00:00 2001
> From: Ken Xue
> Date: Thu, 5 Feb 2015 11:04:44 +0800
> Subject: [PATCH] acpi:apd:add AMD ACPI2Platform device support for x86 system.
>
> This new feature is to int
On Tue, Feb 03, 2015 at 05:55:25PM +0800, Ken Xue wrote:
> On Tue, 2015-02-03 at 11:53 +0200, mika.westerb...@linux.intel.com
> wrote:
> > On Tue, Feb 03, 2015 at 09:04:55AM +0800, Ken Xue wrote:
> > > as you said, platform_drv_probe calls dev_pm_domain_attach(). but
> >
On Tue, Feb 03, 2015 at 09:04:55AM +0800, Ken Xue wrote:
> as you said, platform_drv_probe calls dev_pm_domain_attach(). but
> platform_drv_probe just is a default probe routine. Not all platform
> device drivers use this probe routine. so, codes here may be still
> necessary.
Are you saying that
On Mon, Feb 02, 2015 at 05:50:52PM +0800, Ken Xue wrote:
> >From b9654ecbfaebde00aee746a024eec9fe8de24b97 Mon Sep 17 00:00:00 2001
> From: Ken Xue
> Date: Mon, 2 Feb 2015 17:32:24 +0800
> Subject: [PATCH] This new feature is to interpret AMD specific ACPI device to
> platform device such as I2C,
On Thu, Apr 03, 2014 at 03:34:30PM +0200, Arnd Bergmann wrote:
> On Thursday 03 April 2014 14:38:33 mika.westerb...@linux.intel.com wrote:
> > On Thu, Apr 03, 2014 at 11:25:34AM +, Pallala, Ramakrishna wrote:
> > > >> In non ACPI environment I used to initialize
On Thu, Apr 03, 2014 at 11:25:34AM +, Pallala, Ramakrishna wrote:
> >> In non ACPI environment I used to initialize the platform_data under
> >> board or platforms files. Under ACPI how do I do that?
> >
> >If you can't extract that information from ACPI namespace, then one option
> >is to pa
On Thu, Apr 03, 2014 at 08:10:40AM +, Pallala, Ramakrishna wrote:
> Hi All,
>
> I am trying to enable a i2c client driver under ACPI. The device is being
> enumerated behind adapter device and I am getting IRQ resource as well.
>
> The problem I have now is, how do I pass the platform data t
On Wed, Feb 20, 2013 at 07:36:32AM +, Pallala, Ramakrishna wrote:
> I am looking for tools(Linux or w*s) for editing ACPI tables.
> Can you advise me some good tools. Also I would like to know how BIOS
> engineers populate the ACPI tables? Which tools they use?
Dunno about the BIOS enginee
45 matches
Mail list logo
