Re: [PATCH] pci: Account for virtual buses in pci_acs_path_enabled
On Sun, 2012-08-05 at 23:30 -0600, Bjorn Helgaas wrote:
> On Sat, Aug 4, 2012 at 12:19 PM, Alex Williamson
> wrote:
> > It's possible to have buses without an associated bridge
> > (bus->self == NULL). SR-IOV can generate such buses. When
> > we find these, skip to the parent bus to look for the next
> > ACS test.
>
> To make sure I understand the problem here, I think you're referring
> to the situation where an SR-IOV device can span several bus numbers,
> e.g., the "VFs Spanning Multiple Bus Numbers" implementation note in
> the SR-IOV 1.1 spec, sec. 2.1.2.
>
> It says "All PFs must be located on the Device's captured Bus Number"
> -- I think that means every PF will be directly on a bridge's
> secondary bus and hence will have a valid dev->bus->self pointer.
>
> However, VFs need not be on the same bus number. If a VF is on
> (captured Bus Number plus 1), I think we allocate a new struct pci_bus
> for it, but there's no P2P bridge that leads to that bus, so the
> bus->self pointer is probably NULL.
Yes, exactly. virtfn_add_bus() is where we're creating this new bus.
> This makes me quite nervous, because I bet there are many places that
> assume every non-root bus has a valid bus->self pointer -- I know I
> certainly had that assumption.
>
> I looked at callers of pci_is_root_bus(), and at first glance, it seems like
> iommu_init_device(), intel_iommu_add_device(), pci_acs_path_enabled(),
These 3 are handled by this patch, plus the intel and amd iommu patches
I sent.
> pci_get_interrupt_pin(), pci_common_swizzle(),
If sr-iov is the only source of these virtual buses, these are probably
ok since VFs don't support INTx.
> pci_find_upstream_pcie_bridge(), and
Here the pci_is_root_bus() is after a pci_is_pcie() check, so again if
sr-iov only (and assuming VFs properly report PCIe capability), we
shouldn't stumble on it.
> pci_bus_release_bridge_resources() all might have similar problems.
This one might deserve further investigation. Thanks,
Alex
>
> > Signed-off-by: Alex Williamson
> > ---
> >
> > David Ahern reported an oops from iommu drivers passing NULL into
> > this function for the same mistake. Harden this function against
> > assuming bus->self is valid as well. David, please include this
> > patch as well as the iommu patches in your testing.
> >
> > drivers/pci/pci.c | 22 +-
> > 1 file changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index f3ea977..e11a49c 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -2486,18 +2486,30 @@ bool pci_acs_enabled(struct pci_dev *pdev, u16
> > acs_flags)
> > bool pci_acs_path_enabled(struct pci_dev *start,
> > struct pci_dev *end, u16 acs_flags)
> > {
> > - struct pci_dev *pdev, *parent = start;
> > + struct pci_dev *pdev = start;
> > + struct pci_bus *bus;
> >
> > do {
> > - pdev = parent;
> > -
> > if (!pci_acs_enabled(pdev, acs_flags))
> > return false;
> >
> > - if (pci_is_root_bus(pdev->bus))
> > + bus = pdev->bus;
> > +
> > + if (pci_is_root_bus(bus))
> > return (end == NULL);
> >
> > - parent = pdev->bus->self;
> > + /*
> > +* Skip buses without an associated bridge. In this
> > +* case move to the parent and continue.
> > +*/
> > + while (!bus->self) {
> > + if (!pci_is_root_bus(bus))
> > + bus = bus->parent;
> > + else
> > + return (end == NULL);
> > + }
> > +
> > + pdev = bus->self;
> > } while (pdev != end);
> >
> > return true;
> >
--
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: [GPIO] Crashed when not using
On Tue, Jul 31, 2012 at 6:26 PM, Poddar, Sourav wrote:
> Hi Santosh,
>
> On Tue, Jul 31, 2012 at 6:02 PM, Shilimkar, Santosh
> wrote:
>> On Tue, Jul 31, 2012 at 8:52 AM, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Jul 31, 2012 at 10:23:16AM +0530, Poddar, Sourav wrote:
>>> > The device tree data for acquiring the above GPIO interrupt line
>>> > looks
>>> > like this.
>>> >
>>> > +++ linux-omap-storage/arch/arm/boot/dts/omap5-evm.dts 2012-07-30
>>> > 14:11:08.931694001 +0530
>>> > @@ -42,7 +42,8 @@
>>> > tsl2771@39 {
>>> > compatible = "taos,tsl2771";
>>> > reg = <0x39>;
>>> > +interrupt-parent = <>;
>>> > +interrupts = <21>; /* gpio line 149 */
>>> > };
>>> > };
>>> >
>>> > Note: using "gpio_request_one" in the driver solves the issue.
>>> > Is using this api in the driver required?
>>> > Any pointer on the above crash?
>>> > >>>
>>> > >> Hi Tarun,
>>> > >>> Any user/client driver of GPIO is supposed to go through
>>> > >>> gpio_request() API so that module clock
>>> > >>> is enabled correctly. Overriding of APIs would put the power
>>> > >>> management state machine in jeopardy.
>>> > >>> --
>>> > >> I tried putting "pm_runtime_get_sync" in gpio_irq_type api where the
>>> > >> kernel
>>> > >> is crashing and the crash is no longer observed. So indeed, its about
>>> > >> enabling clocks.
>>> > >>
>>> > >> One doubt: Can't we put runtime apis in "gpio_irq_type" and eliminate
>>> > >> the use of
>>> > >> "gpio_request_one"??
>>> > >
>>> > > No.
>>> > >
>>> > > You must use the GPIO requiest/free APIs to tell the GPIO core that
>>> > > the GPIO line is in use.
>>> > >
>>> > Thanks for this confirmation.
>>> > > Why do you want to avoid using gpio_request/gpio_free?
>>> > >
>>> > I was assuming that DT based gpio IRQ registration will automatically
>>> > take care of
>>> > the above APIs. But since that is not the case(as mentioned by
>>> > santosh), we need to use the
>>> > gpio_request/free apis.
>>>
>>> Hang on for a while, let's try to get to the bottom of this debate first
>>> ;-)
>>>
>>> We have a canonical way of passing IRQ numbers to drivers through DT and
>>> that is the "interrupts" attribute. It shouldn't matter if that IRQ pin
>>> is connected to a real IRQ line or through a GPIO controller. In both
>>> cases we should use the "interrupts" attribute.
>>>
>>> If DT core doesn't allocate the GPIO for us then how does this work:
>>>
>>> (omap4-sdp.dts)
>>>
>>> 127 {
>>> 128 eth@0 {
>>> 129 compatible = "ks8851";
>>> 130 spi-max-frequency = <2400>;
>>> 131 reg = <0>;
>>> 132 interrupt-parent = <>;
>>> 133 interrupts = <2>; /* gpio line 34 */
>>> 134 vdd-supply = <_eth>;
>>> 135 };
>>> 136 };
>>>
>>>
>>> There's no gpio request on the driver:
>>>
>>> $ git grep -e gpio_request drivers/net/ethernet/micrel/ks8851.c
>>> $
>>>
>>> Since Benoit was the one who added that to the dts file (commit
>>> e7c64db9), I assume he tested his patch before posting, so again I ask -
>>> How does that work and why doesn't this work for Sourav's tsl2771
>>> controller ?
>>>
>>> This is either a regression on drivers/of, or commit e7c64db9 is also
>>> broken...
>>>
>>> Benoit, do you know how should this work ?
>>>
>> I had a discussion with Benoit on this. In fact there is a way to actually
>> trigger the GPIO request.
>>
>>> 132 interrupt-parent = <>;
>>> 133 interrupts = <2>; /* gpio line 34 */
>>
>> As above you can see, GPIO2 bank and 2nd line.
>> And then it will make use of gpio_irq chip properties
>> to probe the GPIO line.
>>
>> Saurabh can try this out for his use case.
>>
> I am using the above properties only and seeing the issue.
>
There seeems to be an issue with the GPIO DT probing. The Ethernet
works because there is another GPIO line from BANK2 is probed and since
BANK2 shares the clock, you won't see any issue.
We are looking at fixing the issue. Will keep the thread posted.
Regards
Santosh
--
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] pci: Account for virtual buses in pci_acs_path_enabled
On Sat, Aug 4, 2012 at 12:19 PM, Alex Williamson
wrote:
> It's possible to have buses without an associated bridge
> (bus->self == NULL). SR-IOV can generate such buses. When
> we find these, skip to the parent bus to look for the next
> ACS test.
To make sure I understand the problem here, I think you're referring
to the situation where an SR-IOV device can span several bus numbers,
e.g., the "VFs Spanning Multiple Bus Numbers" implementation note in
the SR-IOV 1.1 spec, sec. 2.1.2.
It says "All PFs must be located on the Device's captured Bus Number"
-- I think that means every PF will be directly on a bridge's
secondary bus and hence will have a valid dev->bus->self pointer.
However, VFs need not be on the same bus number. If a VF is on
(captured Bus Number plus 1), I think we allocate a new struct pci_bus
for it, but there's no P2P bridge that leads to that bus, so the
bus->self pointer is probably NULL.
This makes me quite nervous, because I bet there are many places that
assume every non-root bus has a valid bus->self pointer -- I know I
certainly had that assumption.
I looked at callers of pci_is_root_bus(), and at first glance, it seems like
iommu_init_device(), intel_iommu_add_device(), pci_acs_path_enabled(),
pci_get_interrupt_pin(), pci_common_swizzle(),
pci_find_upstream_pcie_bridge(), and
pci_bus_release_bridge_resources() all might have similar problems.
> Signed-off-by: Alex Williamson
> ---
>
> David Ahern reported an oops from iommu drivers passing NULL into
> this function for the same mistake. Harden this function against
> assuming bus->self is valid as well. David, please include this
> patch as well as the iommu patches in your testing.
>
> drivers/pci/pci.c | 22 +-
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index f3ea977..e11a49c 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2486,18 +2486,30 @@ bool pci_acs_enabled(struct pci_dev *pdev, u16
> acs_flags)
> bool pci_acs_path_enabled(struct pci_dev *start,
> struct pci_dev *end, u16 acs_flags)
> {
> - struct pci_dev *pdev, *parent = start;
> + struct pci_dev *pdev = start;
> + struct pci_bus *bus;
>
> do {
> - pdev = parent;
> -
> if (!pci_acs_enabled(pdev, acs_flags))
> return false;
>
> - if (pci_is_root_bus(pdev->bus))
> + bus = pdev->bus;
> +
> + if (pci_is_root_bus(bus))
> return (end == NULL);
>
> - parent = pdev->bus->self;
> + /*
> +* Skip buses without an associated bridge. In this
> +* case move to the parent and continue.
> +*/
> + while (!bus->self) {
> + if (!pci_is_root_bus(bus))
> + bus = bus->parent;
> + else
> + return (end == NULL);
> + }
> +
> + pdev = bus->self;
> } while (pdev != end);
>
> return true;
>
--
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 v3 1/2] lis3: add generic DT matching code
On 06.08.2012 06:52, Rob Herring wrote:
> On 08/05/2012 11:18 AM, Daniel Mack wrote:
>> Ping, anyone?
>>
>> On 30.07.2012 09:36, Daniel Mack wrote:
>>> This patch adds logic to parse lis3 properties from a device tree node
>>> and store them in a freshly allocated lis3lv02d_platform_data.
>>>
>>> Note that the actual match tables are left out here. This part should
>>> happen in the drivers that bind to the individual busses (SPI/I2C/PCI).
>>>
>>> Also adds some DT bindinds documentation.
>>>
>>> Signed-off-by: Daniel Mack
>>> ---
>>> Changes from v2:
>>> - kzalloc braino
>>>
>>> Changes from v1:
>>> - some typos in properties fixed
>>>
>>>
>>> Documentation/devicetree/bindings/misc/lis302.txt | 74
>>> drivers/misc/lis3lv02d/lis3lv02d.c| 137
>>> ++
>>> drivers/misc/lis3lv02d/lis3lv02d.h| 4 +
>>> 3 files changed, 215 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/misc/lis302.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/misc/lis302.txt
>>> b/Documentation/devicetree/bindings/misc/lis302.txt
>>> new file mode 100644
>>> index 000..66230fd
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/misc/lis302.txt
>>> @@ -0,0 +1,74 @@
>>> +LIS302 accelerometer devicetree bindings
>>> +
>>> +This device is matched via its bus drivers, and has a number of properties
>>> +that apply in on the generic device (independent from the bus).
>>> +
>>> +
>>> +Required properties for the SPI bindings:
>>> + - compatible: should be set to "st,lis3lv02d_spi"
>>> + - reg:the chipselect index
>>> + - spi-max-frequency: maximal bus speed, should be set to 100
>>> unless
>>> + constrained by external circuitry
>>> + - interrupts: the interrupt generated by the device
>>> +
>>> +
>>> +Optional properties for all bus drivers:
>>> +
>>> + - st,click-single-{x,y,z}:if present, tells the device to issue an
>>> + interrupt on single click events on the
>>> + x/y/z axis.
>>> + - st,click-double-{x,y,z}:if present, tells the device to issue an
>>> + interrupt on double click events on the
>>> + x/y/z axis.
>>> + - st,click-thresh-{x,y,z}:set the x/y/z axis threshold
>>> + - st,click-click-time-limit: click time limit, from 0 to 127.5msec
>>> + with step of 0.5 msec
>>> + - st,click-latency: click latency, from 0 to 255 msec with
>>> + step of 1 msec.
>>> + - st,click-window:click window, from 0 to 255 msec with
>>> + step of 1 msec.
>
> These should append "-msec" to define what units they are in.
>
>>> + - st,irq{1,2}-disable:disable IRQ 1/2
>>> + - st,irq{1,2}-ff-wu-1:raise IRQ 1/2 on FF_WU_1 condition
>>> + - st,irq{1,2}-ff-wu-2:raise IRQ 1/2 on FF_WU_2 condition
>>> + - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition
>>> + - st,irq{1,2}-click: raise IRQ 1/2 on click condition
>>> + - st,irq-open-drain: consider IRQ lines open-drain
>>> + - st,irq-active-low: make IRQ lines active low
>>> + - st,wu-duration-1: duration register for Free-Fall/Wake-Up
>>> + interrupt 1
>>> + - st,wu-duration-2: duration register for Free-Fall/Wake-Up
>>> + interrupt 2
>>> + - st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
>>> + upper/lower limit
>>> + - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
>>> + highpass cut-off frequency
>>> + - st,hipass{1,2}-disable: disable highpass 1/2.
>>> + - st,default-rate=: set the default rate
>>> + - st,axis-{x,y,z}=: set the axis to map to the three
>>> coordinates
>
> Wow, that's a lot of properties...
Yes, but that reflects the hardware's capabilities :)
>>> +
>>> +
>>> +Example for a SPI device node:
>>> +
>>> + lis302@0 {
>>> + compatible = "st,lis302dl-spi";
>>> + reg = <0>;
>>> + spi-max-frequency = <100>;
>>> + interrupt-parent = <>;
>>> + interrupts = <104 0>;
>>> +
>>> + st,click-single-x;
>>> + st,click-single-y;
>>> + st,click-single-z;
>>> + st,click-thresh-x = <10>;
>>> + st,click-thresh-y = <10>;
>>> + st,click-thresh-z = <10>;
>>> + st,irq1-click;
>>> + st,irq2-click;
>>> + st,wakeup-x-lo;
>>> + st,wakeup-x-hi;
>>> + st,wakeup-y-lo;
>>> + st,wakeup-y-hi;
>>> + st,wakeup-z-lo;
>>> + st,wakeup-z-hi;
>>> + };
>>> +
>>> diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
>>>
Re: [PATCH] Extcon: adc_jack: adc-jack driver to support 3.5 pi or simliar devices
> From: anish kumar
>
> External connector devices that decides connection information based on
> ADC values may use adc-jack device driver. The user simply needs to
> provide a table of adc range and connection states. Then, extcon
> framework will automatically notify others.
>
> Signed-off-by: anish kumar
Signed-off-by: MyungJoo Ham
> ---
> drivers/extcon/Kconfig |5 +
> drivers/extcon/Makefile |1 +
> drivers/extcon/adc_jack.c | 183
> +++
> include/linux/extcon/adc_jack.h | 108 +++
> 4 files changed, 297 insertions(+), 0 deletions(-)
> create mode 100644 drivers/extcon/adc_jack.c
> create mode 100644 include/linux/extcon/adc_jack.h
>
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index e175c8e..596e277 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -21,6 +21,11 @@ config EXTCON_GPIO
> Say Y here to enable GPIO based extcon support. Note that GPIO
> extcon supports single state per extcon instance.
>
> +config EXTCON_ADC_JACK
> +tristate "ADC Jack extcon support"
> +help
> + Say Y here to enable extcon device driver based on ADC values.
> +
> config EXTCON_MAX77693
> tristate "MAX77693 EXTCON Support"
> depends on MFD_MAX77693
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 88961b3..d95c5ea 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -4,6 +4,7 @@
>
> obj-$(CONFIG_EXTCON) += extcon_class.o
> obj-$(CONFIG_EXTCON_GPIO)+= extcon_gpio.o
> +obj-$(CONFIG_EXTCON_ADC_JACK) += adc_jack.o
> obj-$(CONFIG_EXTCON_MAX77693)+= extcon-max77693.o
> obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
> diff --git a/drivers/extcon/adc_jack.c b/drivers/extcon/adc_jack.c
> new file mode 100644
> index 000..fef8334
> --- /dev/null
> +++ b/drivers/extcon/adc_jack.c
> @@ -0,0 +1,183 @@
> +/*
> + * drivers/extcon/adc_jack.c
> + *
> + * Analog Jack extcon driver with ADC-based detection capability.
> + *
> + * Copyright (C) 2012 Samsung Electronics
> + * MyungJoo Ham
> + *
> + * Modified for calling to IIO to get adc by
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static void adc_jack_handler(struct work_struct *work)
> +{
> + struct adc_jack_data *data = container_of(to_delayed_work(work),
> + struct adc_jack_data,
> + handler);
> + u32 state = 0;
> + int ret, adc_val;
> + int i;
> +
> + if (!data->ready)
> + return;
> +
> + ret = iio_read_channel_raw(data->chan, _val);
> + if (ret < 0) {
> + dev_err(data->edev.dev, "read channel() error: %d\n", ret);
> + return;
> + }
> +
> + /* Get state from adc value with adc_condition */
> + for (i = 0; i < data->num_conditions; i++) {
> + struct adc_jack_cond *def = >adc_condition[i];
> + if (!def->state)
> + break;
> + if (def->min_adc <= adc_val && def->max_adc >= adc_val) {
> + state = def->state;
> + break;
> + }
> + }
> + /* if no def has met, it means state = 0 (no cables attached) */
> +
> + extcon_set_state(>edev, state);
> +}
> +
> +static irqreturn_t adc_jack_irq_thread(int irq, void *_data)
> +{
> + struct adc_jack_data *data = _data;
> +
> + schedule_delayed_work(>handler, data->handling_delay);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int adc_jack_probe(struct platform_device *pdev)
> +{
> + struct adc_jack_data *data;
> + struct adc_jack_pdata *pdata = pdev->dev.platform_data;
> + int i, err = 0;
> +
> + data = kzalloc(sizeof(struct adc_jack_data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + data->edev.name = pdata->name;
> +
> + if (pdata->cable_names)
> + data->edev.supported_cable = pdata->cable_names;
> + else
> + data->edev.supported_cable = extcon_cable_name;
> +
> + /* Check the length of array and set num_cables */
> + for (i = 0; data->edev.supported_cable[i]; i++)
> + ;
> + if (i == 0 || i > SUPPORTED_CABLE_MAX) {
> + err = -EINVAL;
> + dev_err(>dev, "error: pdata->cable_names size = %d\n",
> + i - 1);
> + goto err_alloc;
> + }
> + data->num_cables = i;
> +
> + if (!pdata->adc_condition ||
> + !pdata->adc_condition[0].state) {
> + err = -EINVAL;
> +
Re: [PATCH v2] gpio: Add Avionic Design N-bit GPIO expander support
On Sun, Aug 05, 2012 at 12:50:54PM +0200, Linus Walleij wrote: > On Mon, Jul 30, 2012 at 9:47 AM, Thierry Reding > wrote: > > On Sun, Jul 29, 2012 at 07:13:57PM +0200, Linus Walleij wrote: > >> On Mon, Jul 23, 2012 at 1:59 PM, Thierry Reding > >> wrote: > > >> > +- interrupt-controller: Marks the device as an interrupt controller. > >> > +- nr-gpios: The number of pins supported by the controller. > >> > >> These two last things look very generic, like something every GPIO > >> driver could want to expose. > > > > As Arnd mentioned, interrupt-controller is a generic property required > > by all interrupt controller nodes. Perhaps it shouldn't be listed in the > > DT binding for this driver. > > After reading Rob's etc comments I think nr-gpios should be in this > binding, but interrupt-controller seems like it should go into > Documentation/devicetree/bindings/gpio/gpio.txt > can you take care of this? > > (Anyone agains, beat me up...) Yes, that makes sense. The interrupt-controller property is not explicitly mentioned in Documentation/devicetree at all. Perhaps the reason is that it is in fact a standard property and, I think, is already defined by IEEE 1275. I don't think it would hurt to repeat it explicitly for GPIO bindings in general, though. > >> > +config GPIO_ADNP > >> > + tristate "Avionic Design N-bit GPIO expander" > >> > + depends on I2C && OF > >> > + help > >> > + This option enables support for N GPIOs found on Avionic Design > >> > + I2C GPIO expanders. The register space will be extended by > >> > powers > >> > + of two, so the controller will need to accomodate for that. For > >> > + example: if a controller provides 48 pins, 6 registers will be > >> > + enough to represent all pins, but the driver will assume a > >> > + register layout for 64 pins (8 registers). > >> > + > >> > +config GPIO_ADNP_IRQ > >> > + tristate "Interrupt controller support" > >> > + depends on GPIO_ADNP > >> > + help > >> > + Say yes here to enable the Avionic Design N-bit GPIO expander > >> > to > >> > + be used as an interrupt controller. > >> > >> First: please describe the usecase where the Avionic driver is used > >> without making use of the IRQ, and *why* it should be possible > >> to configure this out. E.g. is there a hardware which isn't using the > >> IRQ portions? If there is no non-irq usecase just drop this > >> config option. > > > > This expander is used in a number of Tegra-based boards and handles > > things like enabling or disabling power to a given IC but on other > > boards it is also used to handle interrupts from input devices or > > card-detect for example. > > > > The controller is synthesized in a CPLD, which is one of the reasons for > > the nr-gpios DT property. There is at least one platform that currently > > doesn't use the interrupt functionality. Mainly I allowed this to be > > configured out in order to reduce the number of interrupts required for > > a platform. Another reason was that at the time I first wrote this, IRQ > > domains hadn't been available, so the driver couldn't be built as a > > module if interrupt support was required. This also no longer applies. > > > > I'm actually fine either way, but I thought it'd be most flexible by > > keeping the IRQ support optional for the above reasons. > > We're working on a goal of a "single zImage" (one unified ARM > kernel) which means your platform must be able to handle the > case where this is turned on anyway, so I would suggest you > drop the optional compile-time IRQ support, just make it > optional at runtime instead. I don't quite understand. Do you want me to add a module parameter to make it optional at runtime? Since the driver is now OF only I suppose I could make it optional on the interrupt-controller property as well. > > On that note, provided there is special additional circuitry, the GPIO > > controller is able to detect tristate on an input. I'm not aware that > > the pinctrl subsystem provides for that functionality yet, right? > > pinctrl is usually about *setting* things into tristate, but I'm all > for adding support for getting it as well. But that depends on > the generic pin configurations being adopted first (still most > controllers have their own way of doing pin config, so this > cannot be represented in a generic way). As I mentioned, the only hardware where this was ever used is already EOL and I don't expect this functionality to be required anytime soon for another project. > >> > + base = kzalloc(regs * 5, GFP_KERNEL); > >> > >> Why kzalloc()/kfree() when you can just use a > >> > >> static u8 base[N]; > >> > >> where N is the max number of registers on any HW instead? > > > > As I explained above, the number of pins is configurable, so it'd be > > quite a waste to always assume a maximum of, say, 256 pins if the > > hardware actually only uses 8. > > OK but atleast find
[PATCH 3/3] perf/x86: Add Intel Westmere-EX uncore support
From: "Yan, Zheng"
The Westmere-EX uncore is similar to the Nehalem-EX uncore. The
differences are:
- Westmere-EX uncore has 10 instances of Cbox. The MSRs for Cbox8
and Cbox9 in the Westmere-EX aren't contiguous with Cbox 0~7.
- The fvid field in the ZDP_CTL_FVC register in the Mbox is
different. It's 5 bits in the Nehalem-EX, 6 bits in the
Westmere-EX.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 56 ++-
arch/x86/kernel/cpu/perf_event_intel_uncore.h | 45 ++---
2 files changed, 68 insertions(+), 33 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 84434e2..0a55710 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -901,16 +901,21 @@ static struct attribute_group
nhmex_uncore_cbox_format_group = {
.attrs = nhmex_uncore_cbox_formats_attr,
};
+/* msr offset for each instance of cbox */
+static unsigned nhmex_cbox_msr_offsets[] = {
+ 0x0, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0, 0x240, 0x2c0,
+};
+
static struct intel_uncore_type nhmex_uncore_cbox = {
.name = "cbox",
.num_counters = 6,
- .num_boxes = 8,
+ .num_boxes = 10,
.perf_ctr_bits = 48,
.event_ctl = NHMEX_C0_MSR_PMON_EV_SEL0,
.perf_ctr = NHMEX_C0_MSR_PMON_CTR0,
.event_mask = NHMEX_PMON_RAW_EVENT_MASK,
.box_ctl= NHMEX_C0_MSR_PMON_GLOBAL_CTL,
- .msr_offset = NHMEX_C_MSR_OFFSET,
+ .msr_offsets= nhmex_cbox_msr_offsets,
.pair_ctr_ctl = 1,
.ops= _uncore_ops,
.format_group = _uncore_cbox_format_group
@@ -1138,6 +1143,9 @@ static struct extra_reg nhmex_uncore_mbox_extra_regs[] = {
EVENT_EXTRA_END
};
+/* Nehalem-EX or Westmere-EX ? */
+bool uncore_nhmex;
+
static bool nhmex_mbox_get_shared_reg(struct intel_uncore_box *box, int idx,
u64 config)
{
struct intel_uncore_extra_reg *er;
@@ -1167,18 +1175,29 @@ static bool nhmex_mbox_get_shared_reg(struct
intel_uncore_box *box, int idx, u64
return false;
/* mask of the shared fields */
- mask = NHMEX_M_PMON_ZDP_CTL_FVC_MASK;
+ if (uncore_nhmex)
+ mask = NHMEX_M_PMON_ZDP_CTL_FVC_MASK;
+ else
+ mask = WSMEX_M_PMON_ZDP_CTL_FVC_MASK;
er = >shared_regs[EXTRA_REG_NHMEX_M_ZDP_CTL_FVC];
raw_spin_lock_irqsave(>lock, flags);
/* add mask of the non-shared field if it's in use */
- if (__BITS_VALUE(atomic_read(>ref), idx, 8))
- mask |= NHMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ if (__BITS_VALUE(atomic_read(>ref), idx, 8)) {
+ if (uncore_nhmex)
+ mask |= NHMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ else
+ mask |= WSMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ }
if (!atomic_read(>ref) || !((er->config ^ config) & mask)) {
atomic_add(1 << (idx * 8), >ref);
- mask = NHMEX_M_PMON_ZDP_CTL_FVC_MASK |
- NHMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ if (uncore_nhmex)
+ mask = NHMEX_M_PMON_ZDP_CTL_FVC_MASK |
+ NHMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ else
+ mask = WSMEX_M_PMON_ZDP_CTL_FVC_MASK |
+ WSMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
er->config &= ~mask;
er->config |= (config & mask);
ret = true;
@@ -1212,7 +1231,10 @@ u64 nhmex_mbox_alter_er(struct perf_event *event, int
new_idx, bool modify)
/* get the non-shared control bits and shift them */
idx = orig_idx - EXTRA_REG_NHMEX_M_ZDP_CTL_FVC;
- config &= NHMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ if (uncore_nhmex)
+ config &= NHMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ else
+ config &= WSMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
if (new_idx > orig_idx) {
idx = new_idx - orig_idx;
config <<= 3 * idx;
@@ -1222,6 +1244,10 @@ u64 nhmex_mbox_alter_er(struct perf_event *event, int
new_idx, bool modify)
}
/* add the shared control bits back */
+ if (uncore_nhmex)
+ config |= NHMEX_M_PMON_ZDP_CTL_FVC_MASK & reg1->config;
+ else
+ config |= WSMEX_M_PMON_ZDP_CTL_FVC_MASK & reg1->config;
config |= NHMEX_M_PMON_ZDP_CTL_FVC_MASK & reg1->config;
if (modify) {
/* adjust the main event selector */
@@ -1480,6 +1506,12 @@ static struct uncore_event_desc
nhmex_uncore_mbox_events[] = {
{ /* end: all zeroes */ },
};
[PATCH 2/3] perf/x86: Fixes for Nehalem-EX uncore driver
From: "Yan, Zheng"
This patch includes following fixes and update:
- Only some events in the Sbox and Mbox can use the match/mask
registers, add code to check this.
- The format definitions for xbr_mm_cfg and xbr_match registers
in the Rbox are wrong, xbr_mm_cfg should use 32 bits, xbr_match
should use 64 bits.
- Cleanup the Rbox code. Compute the addresses extra registers in
the enable_event function instead of the hw_config function.
This simplifies the code in nhmex_rbox_alter_er().
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 195 --
arch/x86/kernel/cpu/perf_event_intel_uncore.h | 1 +
2 files changed, 87 insertions(+), 109 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index a7ccd68..84434e2 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -796,7 +796,6 @@ static struct intel_uncore_type *nhm_msr_uncores[] = {
DEFINE_UNCORE_FORMAT_ATTR(event5, event, "config:1-5");
DEFINE_UNCORE_FORMAT_ATTR(counter, counter, "config:6-7");
-DEFINE_UNCORE_FORMAT_ATTR(mm_cfg, mm_cfg, "config:63");
DEFINE_UNCORE_FORMAT_ATTR(match, match, "config1:0-63");
DEFINE_UNCORE_FORMAT_ATTR(mask, mask, "config2:0-63");
@@ -1032,24 +1031,22 @@ static struct intel_uncore_type nhmex_uncore_bbox = {
static int nhmex_sbox_hw_config(struct intel_uncore_box *box, struct
perf_event *event)
{
- struct hw_perf_event_extra *reg1 = >hw.extra_reg;
- struct hw_perf_event_extra *reg2 = >hw.branch_reg;
+ struct hw_perf_event *hwc = >hw;
+ struct hw_perf_event_extra *reg1 = >extra_reg;
+ struct hw_perf_event_extra *reg2 = >branch_reg;
- if (event->attr.config & NHMEX_S_PMON_MM_CFG_EN) {
- reg1->config = event->attr.config1;
- reg2->config = event->attr.config2;
- } else {
- reg1->config = ~0ULL;
- reg2->config = ~0ULL;
- }
+ /* only TO_R_PROG_EV event uses the match/mask register */
+ if ((hwc->config & NHMEX_PMON_CTL_EV_SEL_MASK) !=
+ NHMEX_S_EVENT_TO_R_PROG_EV)
+ return 0;
if (box->pmu->pmu_idx == 0)
reg1->reg = NHMEX_S0_MSR_MM_CFG;
else
reg1->reg = NHMEX_S1_MSR_MM_CFG;
-
reg1->idx = 0;
-
+ reg1->config = event->attr.config1;
+ reg2->config = event->attr.config2;
return 0;
}
@@ -1059,8 +1056,8 @@ static void nhmex_sbox_msr_enable_event(struct
intel_uncore_box *box, struct per
struct hw_perf_event_extra *reg1 = >extra_reg;
struct hw_perf_event_extra *reg2 = >branch_reg;
- wrmsrl(reg1->reg, 0);
- if (reg1->config != ~0ULL || reg2->config != ~0ULL) {
+ if (reg1->idx != EXTRA_REG_NONE) {
+ wrmsrl(reg1->reg, 0);
wrmsrl(reg1->reg + 1, reg1->config);
wrmsrl(reg1->reg + 2, reg2->config);
wrmsrl(reg1->reg, NHMEX_S_PMON_MM_CFG_EN);
@@ -1074,7 +1071,6 @@ static struct attribute *nhmex_uncore_sbox_formats_attr[]
= {
_attr_edge.attr,
_attr_inv.attr,
_attr_thresh8.attr,
- _attr_mm_cfg.attr,
_attr_match.attr,
_attr_mask.attr,
NULL,
@@ -1264,7 +1260,8 @@ again:
}
/* for the match/mask registers */
- if ((uncore_box_is_fake(box) || !reg2->alloc) &&
+ if (reg2->idx != EXTRA_REG_NONE &&
+ (uncore_box_is_fake(box) || !reg2->alloc) &&
!nhmex_mbox_get_shared_reg(box, reg2->idx, reg2->config))
goto fail;
@@ -1278,7 +1275,8 @@ again:
if (idx[0] != 0xff && idx[0] != __BITS_VALUE(reg1->idx, 0, 8))
nhmex_mbox_alter_er(event, idx[0], true);
reg1->alloc |= alloc;
- reg2->alloc = 1;
+ if (reg2->idx != EXTRA_REG_NONE)
+ reg2->alloc = 1;
}
return NULL;
fail:
@@ -1342,9 +1340,6 @@ static int nhmex_mbox_hw_config(struct intel_uncore_box
*box, struct perf_event
struct extra_reg *er;
unsigned msr;
int reg_idx = 0;
-
- if (WARN_ON_ONCE(reg1->idx != -1))
- return -EINVAL;
/*
* The mbox events may require 2 extra MSRs at the most. But only
* the lower 32 bits in these MSRs are significant, so we can use
@@ -1355,11 +1350,6 @@ static int nhmex_mbox_hw_config(struct intel_uncore_box
*box, struct perf_event
continue;
if (event->attr.config1 & ~er->valid_mask)
return -EINVAL;
- if (er->idx == __BITS_VALUE(reg1->idx, 0, 8) ||
- er->idx == __BITS_VALUE(reg1->idx, 1, 8))
- continue;
- if (WARN_ON_ONCE(reg_idx >= 2))
- return -EINVAL;
msr = er->msr +
[PATCH 1/3] perf/x86: Fix section mismatch in uncore_types_exit()
From: "Yan, Zheng"
Fix section mismatch in uncore_types_exit():
WARNING: vmlinux.o(.text+0x13831): Section mismatch in
reference from the function uncore_types_exit() to the
function .init.text:uncore_type_exit()
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 7563fda..a7ccd68 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -2373,7 +2373,7 @@ static void __init uncore_type_exit(struct
intel_uncore_type *type)
type->attr_groups[1] = NULL;
}
-static void uncore_types_exit(struct intel_uncore_type **types)
+static void __init uncore_types_exit(struct intel_uncore_type **types)
{
int i;
for (i = 0; types[i]; i++)
--
1.7.11.2
--
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/
how to implement platform specific per process parameter?
Hi!
There is a per core register on modern POWER processors (POWER6+) called
"DSCR": The DSCR (aka Data Stream Control Register) is supported on some
server PowerPC chips and allow some control over the prefetch of data
streams.
Its "per process" support has been added by
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=efcac6589a277c10060e4be44b9455cf43838dc1
"powerpc: Per process DSCR + some fixes (try#4)"
The patch adds the DSCR value into "struct thread_struct" and
saves/restores it when the context is switched. Also, there is some policy
to initialize the register when a thread starts. So far so good.
Here is the problem.
Some customer(s) of this feature want an ability to change the DSCR value
of the already running process. I.e. we need some kernel interface which
would accept pid and the register value and change it.
There are 4 options:
1. [not a kernel interface] use ptrace to execute the register changing
command inside the specified pid. The next context switch saves the new
value in the thread_struct. Dirty hack.
2. Add a new syscall which would receive pid + register value and do the
job. A bit too much.
3. Add some hook in /proc filesystem but so far there were no platform
specific bits, right?
4. Implement a static node "/sys/devices/system/cpu/dscr_control". write()
would parse the input stream, call scanf("%d %x", , ) and do the job.
What is the correct approach? Thanks.
--
Alexey
--
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: linux-next: build failure after merge of the akpm tree
gfs2 calls RB_EMPTY_NODE() to check if nodes are not on an rbtree. The corresponding initialization function is RB_CLEAR_NODE(). rb_init_node() was never clearly defined and is going away. Signed-off-by: Michel Lespinasse --- fs/gfs2/rgrp.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c index eaa4188..675e7cc 100644 --- a/fs/gfs2/rgrp.c +++ b/fs/gfs2/rgrp.c @@ -487,7 +487,7 @@ int gfs2_rs_alloc(struct gfs2_inode *ip) if (!res) error = -ENOMEM; - rb_init_node(>rs_node); + RB_CLEAR_NODE(>rs_node); down_write(>i_rw_mutex); if (ip->i_res) @@ -520,7 +520,7 @@ static void __rs_deltree(struct gfs2_inode *ip, struct gfs2_blkreserv *rs) rgd = rs->rs_rbm.rgd; trace_gfs2_rs(ip, rs, TRACE_RS_TREEDEL); rb_erase(>rs_node, >rd_rstree); - rb_init_node(>rs_node); + RB_CLEAR_NODE(>rs_node); BUG_ON(!rgd->rd_rs_cnt); rgd->rd_rs_cnt--; -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- 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: linux-next: build failure after merge of the akpm tree
On Sun, Aug 5, 2012 at 8:43 PM, Stephen Rothwell wrote:
> Caused by commit 5599fe1ab023 ("rbtree: empty nodes have no color") from
> the akpm tree interacting with commit cde7c325077b ("GFS2: Add structure
> to contain rgrp, bitmap, offset tuple") from the gfs2 tree.
>
> I have applied the following merge fix patch (which is probably not
> sufficient).
You are right that this is insufficient - gfs2 is using
RB_EMPTY_NODE() to check for nodes not being inserted on any rbtree,
so it must use RB_CLEAR_NODE() for initialization.
Will attach a patch as a reply to this.
I am surprised how fast these rb_init_node() calls are spreading.
Should I send Linus a patch removing that function so he could include
it in v3.6 and avoid having to deal with all these new uses ?
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
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] backlight: da9052: Use usleep_range() instead of msleep() for small sleeps
On Monday, August 06, 2012 1:48 PM Sachin Kamat wrote:
>
> Hi Jingoo,
>
> On 6 August 2012 10:13, Jingoo Han wrote:
> > Since msleep might not sleep for the desired amount when less
> > than 20ms, use usleep_range.
> >
> > Cc: Ashish Jangam
> > Cc: Richard Purdie
> > Signed-off-by: Jingoo Han
> > ---
> > drivers/video/backlight/da9052_bl.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/video/backlight/da9052_bl.c
> > b/drivers/video/backlight/da9052_bl.c
> > index b628d68..10485c9 100644
> > --- a/drivers/video/backlight/da9052_bl.c
> > +++ b/drivers/video/backlight/da9052_bl.c
> > @@ -72,7 +72,7 @@ static int da9052_adjust_wled_brightness(struct da9052_bl
> > *wleds)
> > if (ret < 0)
> > return ret;
> >
> > - msleep(10);
> > + usleep_range(1, 11000);
>
> Can't we just use usleep(1) instead?
usleep() is not available.
For more details, refer to Documentation/timers/timers-howto.txt.
>
>
> >
> > if (wleds->brightness) {
> > ret = da9052_reg_write(wleds->da9052,
> > wled_bank[wleds->led_reg],
> > --
> > 1.7.1
> >
> >
> > --
> > 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/
>
>
>
> --
> With warm regards,
> Sachin
--
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/
[PATCH] Extcon: adc_jack: adc-jack driver to support 3.5 pi or simliar devices
From: anish kumar
External connector devices that decides connection information based on
ADC values may use adc-jack device driver. The user simply needs to
provide a table of adc range and connection states. Then, extcon
framework will automatically notify others.
Signed-off-by: anish kumar
---
drivers/extcon/Kconfig |5 +
drivers/extcon/Makefile |1 +
drivers/extcon/adc_jack.c | 183 +++
include/linux/extcon/adc_jack.h | 108 +++
4 files changed, 297 insertions(+), 0 deletions(-)
create mode 100644 drivers/extcon/adc_jack.c
create mode 100644 include/linux/extcon/adc_jack.h
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index e175c8e..596e277 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -21,6 +21,11 @@ config EXTCON_GPIO
Say Y here to enable GPIO based extcon support. Note that GPIO
extcon supports single state per extcon instance.
+config EXTCON_ADC_JACK
+tristate "ADC Jack extcon support"
+help
+ Say Y here to enable extcon device driver based on ADC values.
+
config EXTCON_MAX77693
tristate "MAX77693 EXTCON Support"
depends on MFD_MAX77693
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 88961b3..d95c5ea 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -4,6 +4,7 @@
obj-$(CONFIG_EXTCON) += extcon_class.o
obj-$(CONFIG_EXTCON_GPIO) += extcon_gpio.o
+obj-$(CONFIG_EXTCON_ADC_JACK) += adc_jack.o
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
diff --git a/drivers/extcon/adc_jack.c b/drivers/extcon/adc_jack.c
new file mode 100644
index 000..fef8334
--- /dev/null
+++ b/drivers/extcon/adc_jack.c
@@ -0,0 +1,183 @@
+/*
+ * drivers/extcon/adc_jack.c
+ *
+ * Analog Jack extcon driver with ADC-based detection capability.
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * MyungJoo Ham
+ *
+ * Modified for calling to IIO to get adc by
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void adc_jack_handler(struct work_struct *work)
+{
+ struct adc_jack_data *data = container_of(to_delayed_work(work),
+ struct adc_jack_data,
+ handler);
+ u32 state = 0;
+ int ret, adc_val;
+ int i;
+
+ if (!data->ready)
+ return;
+
+ ret = iio_read_channel_raw(data->chan, _val);
+ if (ret < 0) {
+ dev_err(data->edev.dev, "read channel() error: %d\n", ret);
+ return;
+ }
+
+ /* Get state from adc value with adc_condition */
+ for (i = 0; i < data->num_conditions; i++) {
+ struct adc_jack_cond *def = >adc_condition[i];
+ if (!def->state)
+ break;
+ if (def->min_adc <= adc_val && def->max_adc >= adc_val) {
+ state = def->state;
+ break;
+ }
+ }
+ /* if no def has met, it means state = 0 (no cables attached) */
+
+ extcon_set_state(>edev, state);
+}
+
+static irqreturn_t adc_jack_irq_thread(int irq, void *_data)
+{
+ struct adc_jack_data *data = _data;
+
+ schedule_delayed_work(>handler, data->handling_delay);
+
+ return IRQ_HANDLED;
+}
+
+static int adc_jack_probe(struct platform_device *pdev)
+{
+ struct adc_jack_data *data;
+ struct adc_jack_pdata *pdata = pdev->dev.platform_data;
+ int i, err = 0;
+
+ data = kzalloc(sizeof(struct adc_jack_data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->edev.name = pdata->name;
+
+ if (pdata->cable_names)
+ data->edev.supported_cable = pdata->cable_names;
+ else
+ data->edev.supported_cable = extcon_cable_name;
+
+ /* Check the length of array and set num_cables */
+ for (i = 0; data->edev.supported_cable[i]; i++)
+ ;
+ if (i == 0 || i > SUPPORTED_CABLE_MAX) {
+ err = -EINVAL;
+ dev_err(>dev, "error: pdata->cable_names size = %d\n",
+ i - 1);
+ goto err_alloc;
+ }
+ data->num_cables = i;
+
+ if (!pdata->adc_condition ||
+ !pdata->adc_condition[0].state) {
+ err = -EINVAL;
+ dev_err(>dev, "error: adc_condition not defined.\n");
+ goto err_alloc;
+ }
+ data->adc_condition = pdata->adc_condition;
+
+ /* Check the length of array and set num_conditions */
+
Re: [PATCH v3 1/2] lis3: add generic DT matching code
On 08/05/2012 11:18 AM, Daniel Mack wrote:
> Ping, anyone?
>
> On 30.07.2012 09:36, Daniel Mack wrote:
>> This patch adds logic to parse lis3 properties from a device tree node
>> and store them in a freshly allocated lis3lv02d_platform_data.
>>
>> Note that the actual match tables are left out here. This part should
>> happen in the drivers that bind to the individual busses (SPI/I2C/PCI).
>>
>> Also adds some DT bindinds documentation.
>>
>> Signed-off-by: Daniel Mack
>> ---
>> Changes from v2:
>> - kzalloc braino
>>
>> Changes from v1:
>> - some typos in properties fixed
>>
>>
>> Documentation/devicetree/bindings/misc/lis302.txt | 74
>> drivers/misc/lis3lv02d/lis3lv02d.c| 137
>> ++
>> drivers/misc/lis3lv02d/lis3lv02d.h| 4 +
>> 3 files changed, 215 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/misc/lis302.txt
>>
>> diff --git a/Documentation/devicetree/bindings/misc/lis302.txt
>> b/Documentation/devicetree/bindings/misc/lis302.txt
>> new file mode 100644
>> index 000..66230fd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/lis302.txt
>> @@ -0,0 +1,74 @@
>> +LIS302 accelerometer devicetree bindings
>> +
>> +This device is matched via its bus drivers, and has a number of properties
>> +that apply in on the generic device (independent from the bus).
>> +
>> +
>> +Required properties for the SPI bindings:
>> + - compatible: should be set to "st,lis3lv02d_spi"
>> + - reg: the chipselect index
>> + - spi-max-frequency: maximal bus speed, should be set to 100
>> unless
>> +constrained by external circuitry
>> + - interrupts: the interrupt generated by the device
>> +
>> +
>> +Optional properties for all bus drivers:
>> +
>> + - st,click-single-{x,y,z}: if present, tells the device to issue an
>> +interrupt on single click events on the
>> +x/y/z axis.
>> + - st,click-double-{x,y,z}: if present, tells the device to issue an
>> +interrupt on double click events on the
>> +x/y/z axis.
>> + - st,click-thresh-{x,y,z}: set the x/y/z axis threshold
>> + - st,click-click-time-limit: click time limit, from 0 to 127.5msec
>> +with step of 0.5 msec
>> + - st,click-latency:click latency, from 0 to 255 msec with
>> +step of 1 msec.
>> + - st,click-window: click window, from 0 to 255 msec with
>> +step of 1 msec.
These should append "-msec" to define what units they are in.
>> + - st,irq{1,2}-disable: disable IRQ 1/2
>> + - st,irq{1,2}-ff-wu-1: raise IRQ 1/2 on FF_WU_1 condition
>> + - st,irq{1,2}-ff-wu-2: raise IRQ 1/2 on FF_WU_2 condition
>> + - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition
>> + - st,irq{1,2}-click: raise IRQ 1/2 on click condition
>> + - st,irq-open-drain: consider IRQ lines open-drain
>> + - st,irq-active-low: make IRQ lines active low
>> + - st,wu-duration-1:duration register for Free-Fall/Wake-Up
>> +interrupt 1
>> + - st,wu-duration-2:duration register for Free-Fall/Wake-Up
>> +interrupt 2
>> + - st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
>> +upper/lower limit
>> + - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
>> +highpass cut-off frequency
>> + - st,hipass{1,2}-disable: disable highpass 1/2.
>> + - st,default-rate=:set the default rate
>> + - st,axis-{x,y,z}=:set the axis to map to the three
>> coordinates
Wow, that's a lot of properties...
>> +
>> +
>> +Example for a SPI device node:
>> +
>> +lis302@0 {
>> +compatible = "st,lis302dl-spi";
>> +reg = <0>;
>> +spi-max-frequency = <100>;
>> +interrupt-parent = <>;
>> +interrupts = <104 0>;
>> +
>> +st,click-single-x;
>> +st,click-single-y;
>> +st,click-single-z;
>> +st,click-thresh-x = <10>;
>> +st,click-thresh-y = <10>;
>> +st,click-thresh-z = <10>;
>> +st,irq1-click;
>> +st,irq2-click;
>> +st,wakeup-x-lo;
>> +st,wakeup-x-hi;
>> +st,wakeup-y-lo;
>> +st,wakeup-y-hi;
>> +st,wakeup-z-lo;
>> +st,wakeup-z-hi;
>> +};
>> +
>> diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
>> b/drivers/misc/lis3lv02d/lis3lv02d.c
>> index a981e2a..1411fdc 100644
>> --- a/drivers/misc/lis3lv02d/lis3lv02d.c
>> +++ b/drivers/misc/lis3lv02d/lis3lv02d.c
>> @@ -39,6 +39,7 @@
>> #include
>> #include
>>
Re: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Sun, Aug 05, 2012 at 07:20:31PM -0400, Alex Deucher wrote: > On Sun, Aug 5, 2012 at 5:44 PM, Dave Airlie wrote: > > On Mon, Aug 6, 2012 at 7:40 AM, Daniel Vetter wrote: > >> On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote: > >>> On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote: > >>> > >>> > I like this approach more - the only other solution I see is to ask the > >>> > currently active driver (i.e. radeon) at bootime for the right mode. > >>> > Which > >>> > sounds much more hellish and fragile ... > >>> > >>> The "correct" approach is clearly to just have the drm core change the > >>> i2c mux before requesting edid, but that's made difficult because of the > >>> absence of ordering guarantees in initialisation. I don't like quirking > >>> this, since we're then back to the situation of potentially having to > >>> add every new piece of related hardware to the quirk list. > >> > >> The "correct" approach of switching the mux before we fetch the edid is > >> actualy the one I fear will result in fragile code: Only run on few > >> machines, and as you say with tons of funky interactions with the init > >> sequence ordering. And I guess people will bitch about the flickering > >> this will cause ;-) > >> > >> As long as it's only apple shipping multi-gpu machines with > >> broken/non-existing vbt, I'll happily stomach the quirk list entries. > >> They're bad, but imo the lesser evil. > > > > Well in theory you can switch the ddc lines without switching the other > > lines, > > so we could do a mutex protected mux switch around edid retrival, > > > > Depends on the system. On non-Macs, some systems have a single mux, > others have a separate mux for i2c and display as specified in the > ATPX ACPI methods. Not sure how the Macs do it. I've started > cleaning up the PX radeon code along with a bunch of other radeon > ralated ACPI fixes: > http://cgit.freedesktop.org/~agd5f/linux/log/?h=acpi_patches The Macs mux the i2c and display separately. However they don't support the vendor ACPI interfaces for the mux. The driver that provides the vga_switcheroo handler is separate from the graphics drivers, and the same whether the discrete graphics are Radeon or nVidia. Really to support this in any generic sort of way vga_switcheroo needs to support muxing the DDC separately from the display, but as Matthew pointed out the ordering of initialization could be a problem. Even if we protect the DDC with a mutex how can we guarantee that the switcheroo handler is registered to switch the DDC before i915 is ready to check for an EDID? -- 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] pci: Account for virtual buses in pci_acs_path_enabled
On 8/4/12 12:19 PM, Alex Williamson wrote: It's possible to have buses without an associated bridge (bus->self == NULL). SR-IOV can generate such buses. When we find these, skip to the parent bus to look for the next ACS test. Signed-off-by: Alex Williamson --- David Ahern reported an oops from iommu drivers passing NULL into this function for the same mistake. Harden this function against assuming bus->self is valid as well. David, please include this patch as well as the iommu patches in your testing. Tested-by: David Ahern -- 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/2] intel-iommu: Fix ACS path checking
On 8/4/12 12:08 PM, Alex Williamson wrote: SR-IOV can create buses without a bridge. There may be other cases where this happens as well. In these cases skip to the parent bus and continue testing devices there. Signed-off-by: Alex Williamson Tested-by: David Ahern -- 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: [RFC][PATCH] Reset PCIe devices to address DMA problem on kdump with iommu
Hi Don,
(2012/08/06 13:09), Don Dutile wrote:
> On 08/03/2012 07:24 AM, Takao Indoh wrote:
>> Hi all,
>>
>> This patch adds kernel parameter "reset_pcie_devices" which resets PCIe
>> devices at boot time to address DMA problem on kdump with iommu. When
>> this parameter is specified, a hot reset is triggered on each PCIe root
>> port and downstream port to reset its downstream endpoint.
>>
>> Background:
>> A kdump problem about DMA has been discussed for a long time. That is,
>> when a kernel is switched to the kdump kernel DMA derived from first
>> kernel affects second kernel. Recently this problem surfaces when iommu
>> is used for PCI passthrough on KVM guest. In the case of the machine I
>> use, when intel_iommu=on is specified, DMAR error is detected in kdump
>> kernel and PCI SERR is also detected. Finally kdump fails because some
>> devices does not work correctly.
>>
>> The root cause is that ongoing DMA from first kernel causes DMAR fault
>> because page table of DMAR is initialized while kdump kernel is booting
>> up. Therefore to address this problem DMA needs to be stopped before DMAR
>> is initialized at kdump kernel boot time. By this patch, PCIe devices
>> are reset by hot reset and its DMA is stopped when reset_pcie_devices is
>> specified. One problem of this solution is that VGA is reset and the
>> monitor blacks out when the link between the port and VGA controller was
>> reset. So this patch does not reset the port whose child endpoint is VGA
>> device.
>>
>> Any comments would be appreciated.
>>
>> Signed-off-by: Takao Indoh
>> ---
> Have you considered something less disruptive such as clearing the
> Master Enable in each endpoint's PCI Command Register ?
> That should prevent DMA transactions from endpoints during the kdump and
> kexec, and when the driver for the device gets reconfigured,
> Master Enable will be set back on, but after the driver has had the
> opportunity to do a device-specific reset.
Yes, that is what I tried first. First of all I found this thread.
[PATCH] Disable Bus Master on PCI device shutdown
https://lkml.org/lkml/2012/6/6/278
original patch: http://marc.info/?l=kexec=133546519231295=2
And I thought ongoing DMA could be stopped by disabling it on kdump
kernel boot, but DMAR error is still found after adding quirk below.
In this thread, AER link reset was also suggested, so I got the
idea to reset root port and downstream port.
Thanks,
Takao Indoh
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 5155317..0e8b41a 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -31,6 +31,22 @@
#include/* isa_dma_bridge_buggy */
#include "pci.h"
+static void test_pci_device_reset(struct pci_dev *dev)
+{
+ u16 pci_command;
+
+ if (!reset_devices)
+ return;
+
+ pci_read_config_word(dev, PCI_COMMAND, _command);
+ if (pci_command & PCI_COMMAND_MASTER) {
+ dev_info(>dev, "DEBUG: Disable Bus Master bit\n");
+ pci_command &= ~PCI_COMMAND_MASTER;
+ pci_write_config_word(dev, PCI_COMMAND, pci_command);
+ }
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_ANY_ID, PCI_ANY_ID, test_pci_device_reset);
+
/*
* Decoding should be disabled for a PCI device during BAR sizing to avoid
* conflict. But doing so may cause problems on host bridge and perhaps other
--
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/
[PATCH 3/4] perf tools: Support minimal build without libelf
From: Namhyung Kim
Now we have isolated all ELF-specific stuff, it's possible to build
without libelf. The output binary can do most of jobs but lacks (user
level) symbol information - kernel symbols are still accessable thanks
to the kallsyms.
To build perf without libelf (elfutils), give NO_LIBELF=1 to make.
For now, only 'perf probe' command is removed since it depends on
libelf/libdw heavily.
Signed-off-by: Namhyung Kim
---
tools/perf/Makefile | 57 -
tools/perf/builtin-inject.c | 5 +++-
tools/perf/command-list.txt | 2 +-
tools/perf/perf.c | 2 ++
tools/perf/util/generate-cmdlist.sh | 15 ++
tools/perf/util/map.c | 3 +-
tools/perf/util/symbol-minimal.c| 39 +
7 files changed, 106 insertions(+), 17 deletions(-)
create mode 100644 tools/perf/util/symbol-minimal.c
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index a25162a858ab..1b7dcc641f11 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -37,7 +37,12 @@ include config/utilities.mak
#
# Define NO_NEWT if you do not want TUI support.
#
+# Define NO_GTK2 if you do not want GTK+ GUI support.
+#
# Define NO_DEMANGLE if you do not want C++ symbol demangling.
+#
+# Define NO_LIBELF if you do not want libelf dependency (e.g. cross-builds)
+#
$(OUTPUT)PERF-VERSION-FILE: .FORCE-PERF-VERSION-FILE
@$(SHELL_PATH) util/PERF-VERSION-GEN $(OUTPUT)
@@ -446,34 +451,57 @@ PYRF_OBJS += $(OUTPUT)util/xyarray.o
-include config.mak.autogen
-include config.mak
-ifndef NO_DWARF
-FLAGS_DWARF=$(ALL_CFLAGS) -ldw -lelf $(ALL_LDFLAGS) $(EXTLIBS)
-ifneq ($(call try-cc,$(SOURCE_DWARF),$(FLAGS_DWARF)),y)
- msg := $(warning No libdw.h found or old libdw.h found or elfutils is
older than 0.138, disables dwarf support. Please install new
elfutils-devel/libdw-dev);
+ifdef NO_LIBELF
NO_DWARF := 1
-endif # Dwarf support
-endif # NO_DWARF
-
--include arch/$(ARCH)/Makefile
-
-ifneq ($(OUTPUT),)
- BASIC_CFLAGS += -I$(OUTPUT)
-endif
-
+ NO_DEMANGLE := 1
+else
FLAGS_LIBELF=$(ALL_CFLAGS) $(ALL_LDFLAGS) $(EXTLIBS)
ifneq ($(call try-cc,$(SOURCE_LIBELF),$(FLAGS_LIBELF)),y)
FLAGS_GLIBC=$(ALL_CFLAGS) $(ALL_LDFLAGS)
ifneq ($(call try-cc,$(SOURCE_GLIBC),$(FLAGS_GLIBC)),y)
msg := $(error No gnu/libc-version.h found, please install
glibc-dev[el]/glibc-static);
else
- msg := $(error No libelf.h/libelf found, please install
libelf-dev/elfutils-libelf-devel);
+ NO_LIBELF := 1
+ NO_DWARF := 1
+ NO_DEMANGLE := 1
endif
endif
+endif # NO_LIBELF
+
+-include arch/$(ARCH)/Makefile
+
+ifneq ($(OUTPUT),)
+ BASIC_CFLAGS += -I$(OUTPUT)
+endif
+
+ifdef NO_LIBELF
+BASIC_CFLAGS += -DNO_LIBELF_SUPPORT
+
+EXTLIBS := $(filter-out -lelf,$(EXTLIBS))
+
+# Remove ELF/DWARF dependent codes
+LIB_OBJS := $(filter-out $(OUTPUT)util/symbol-elf.o,$(LIB_OBJS))
+LIB_OBJS := $(filter-out $(OUTPUT)util/dwarf-aux.o,$(LIB_OBJS))
+LIB_OBJS := $(filter-out $(OUTPUT)util/probe-event.o,$(LIB_OBJS))
+LIB_OBJS := $(filter-out $(OUTPUT)util/probe-finder.o,$(LIB_OBJS))
+
+BUILTIN_OBJS := $(filter-out $(OUTPUT)builtin-probe.o,$(BUILTIN_OBJS))
+
+# Use minimal symbol handling
+LIB_OBJS += $(OUTPUT)util/symbol-minimal.o
+
+else # NO_LIBELF
ifneq ($(call try-cc,$(SOURCE_ELF_MMAP),$(FLAGS_COMMON)),y)
BASIC_CFLAGS += -DLIBELF_NO_MMAP
endif
+FLAGS_DWARF=$(ALL_CFLAGS) -ldw -lelf $(ALL_LDFLAGS) $(EXTLIBS)
+ifneq ($(call try-cc,$(SOURCE_DWARF),$(FLAGS_DWARF)),y)
+ msg := $(warning No libdw.h found or old libdw.h found or elfutils is
older than 0.138, disables dwarf support. Please install new
elfutils-devel/libdw-dev);
+ NO_DWARF := 1
+endif # Dwarf support
+
ifndef NO_DWARF
ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
msg := $(warning DWARF register mappings have not been defined for
architecture $(ARCH), DWARF support disabled);
@@ -484,6 +512,7 @@ else
LIB_OBJS += $(OUTPUT)util/dwarf-aux.o
endif # PERF_HAVE_DWARF_REGS
endif # NO_DWARF
+endif # NO_LIBELF
ifdef NO_NEWT
BASIC_CFLAGS += -DNO_NEWT_SUPPORT
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 3beab489afc5..64d8ba2fb7bc 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -191,10 +191,13 @@ static int perf_event__inject_buildid(struct perf_tool
*tool,
* If this fails, too bad, let the other side
* account this as unresolved.
*/
- } else
+ } else {
+#ifndef NO_LIBELF_SUPPORT
pr_warning("no symbols found in %s, maybe "
"install a debug package?\n",
al.map->dso->long_name);
+#endif
+
[PATCH 1/4] perf symbols: Introduce symbol__elf_init()
From: Namhyung Kim
The symbol__elf_init() is for initializing internal libelf
data structure and getting rid of its dependency outside of
ELF/symboling handling code.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-buildid-list.c | 4 +---
tools/perf/util/symbol.c | 8 +++-
tools/perf/util/symbol.h | 1 +
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-buildid-list.c
b/tools/perf/builtin-buildid-list.c
index 6b2bcfbde150..7d6842826a0c 100644
--- a/tools/perf/builtin-buildid-list.c
+++ b/tools/perf/builtin-buildid-list.c
@@ -16,8 +16,6 @@
#include "util/session.h"
#include "util/symbol.h"
-#include
-
static const char *input_name;
static bool force;
static bool show_kernel;
@@ -71,7 +69,7 @@ static int perf_session__list_build_ids(void)
{
struct perf_session *session;
- elf_version(EV_CURRENT);
+ symbol__elf_init();
session = perf_session__new(input_name, O_RDONLY, force, false,
_id__mark_dso_hit_ops);
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index fdad4eeeb429..41faa6c41e87 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1453,6 +1453,11 @@ out_close:
return err;
}
+void symbol__elf_init(void)
+{
+ elf_version(EV_CURRENT);
+}
+
static bool dso__build_id_equal(const struct dso *dso, u8 *build_id)
{
return memcmp(dso->build_id, build_id, sizeof(dso->build_id)) == 0;
@@ -2754,7 +2759,8 @@ int symbol__init(void)
symbol_conf.priv_size = ALIGN(symbol_conf.priv_size, sizeof(u64));
- elf_version(EV_CURRENT);
+ symbol__elf_init();
+
if (symbol_conf.sort_by_name)
symbol_conf.priv_size += (sizeof(struct symbol_name_rb_node) -
sizeof(struct symbol));
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 1fe733a1e21f..355993d3abbf 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -309,6 +309,7 @@ void machines__destroy_guest_kernel_maps(struct rb_root
*machines);
int symbol__init(void);
void symbol__exit(void);
+void symbol__elf_init(void);
size_t symbol__fprintf_symname_offs(const struct symbol *sym,
const struct addr_location *al, FILE *fp);
size_t symbol__fprintf_symname(const struct symbol *sym, FILE *fp);
--
1.7.11.2
--
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/
[PATCHSET 0/4] perf tools: Minimal build without libelf dependency (v4)
Hi, This is my forth version of the series. Please consider applying. :) v4: * rebase on current tip/perf/core v3: * drop already merged (cross-build related) patches * drop SYMBIND_* change (Arnaldo) v2: * change make option name to NO_LIBELF * make it default when libelf doesn't exist (Ingo) * get rid of elf-minimal.h and use elf.h (Jiri) Original description follows: -- Current build procedure of perf tools requires a couple of external libraries. Although most of them are optional, elfutils' libelf is mandatory for resolving symbols and build-id of the binaries being profiled. For some reason, it makes embedded guys' life harder who want to build and run perf tools on their boards. This patchset tries to fix the problem by letting the perf could be built without the libelf. The initial intent was just providing perf record command to gather performance events interested on the system and copies perf.data to development box to be used by (full- fledged) perf report for analysis. However it's changed to have most of perf commands as is because perf can resolve kernel symbols without libelf and many of perf commands deal (mostly) with kernel events - so no need to restrict capability of perf tools. Therefore, the end result is not so minimalistic actually and the only thing it cannot do is "perf probe". And there's a poor man's version of ELF parser only for parsing the build-id info. While it's not absolutely needed, I think it's good to have, just in case. In addition, I changed my mind to keep unrelated configurations - i.g. tui/gui and perf/python support - enabled by default so that it can be configured by a find-grained config method in the future. To build a minimal perf tools explicitly, pass NO_LIBELF=1 to make. Or, if the system doesn't provide the elfutils it'll detect that and converts to the minimal build mode automatically. The resulting perf report will not display symbol names in userland: # Samples: 3K of event 'cycles' # Event count (approx.): 3740267998 # # Overhead Command Shared Object Symbol # ... . .. # 99.70% noploop noploop[.] 0x066d 0.10% noploop [kernel.kallsyms] [k] free_pgd_range 0.03% noploop [kernel.kallsyms] [k] native_write_msr_safe 0.03% noploop [kernel.kallsyms] [k] raise_softirq 0.03% noploop [kernel.kallsyms] [k] rb_insert_color But perf buildid-list can show the build-id's: $ ./perf buildid-list --with-hits 5eaf1839576cc801053e63300762def90a77a305 [kernel.kallsyms] 43a7a2b399b6ee2ff29c6bdadbda6bff88712ed4 /home/namhyung/bin/noploop So it can be packed using perf archive command and copied and analized with full-fledged perf tools on a development machine. Namhyung Kim (4): perf symbols: Introduce symbol__elf_init() perf tools: Split out util/symbol-elf.c perf tools: Support minimal build without libelf perf symbols: Implement poor man's ELF parser tools/perf/Makefile | 58 ++- tools/perf/builtin-buildid-list.c | 4 +- tools/perf/builtin-inject.c | 5 +- tools/perf/command-list.txt | 2 +- tools/perf/perf.c | 2 + tools/perf/util/generate-cmdlist.sh | 15 + tools/perf/util/map.c | 22 +- tools/perf/util/map.h | 1 + tools/perf/util/symbol-elf.c| 775 ++ tools/perf/util/symbol-minimal.c| 267 tools/perf/util/symbol.c| 802 +--- tools/perf/util/symbol.h| 16 + 12 files changed, 1156 insertions(+), 813 deletions(-) create mode 100644 tools/perf/util/symbol-elf.c create mode 100644 tools/perf/util/symbol-minimal.c -- 1.7.11.2 -- 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 0/4] promote zcache from staging
On Tue, Jul 31, 2012 at 11:36:04AM -0400, Konrad Rzeszutek Wilk wrote: > On Sun, Jul 29, 2012 at 10:54:28AM +0900, Minchan Kim wrote: > > On Fri, Jul 27, 2012 at 02:42:14PM -0700, Dan Magenheimer wrote: > > > > From: Konrad Rzeszutek Wilk [mailto:kon...@darnok.org] > > > > Sent: Friday, July 27, 2012 3:00 PM > > > > Subject: Re: [PATCH 0/4] promote zcache from staging > > > > > > > > On Fri, Jul 27, 2012 at 12:21:50PM -0700, Dan Magenheimer wrote: > > > > > > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > > > > > > Subject: [PATCH 0/4] promote zcache from staging > > > > > > > > > > > > zcache is the remaining piece of code required to support in-kernel > > > > > > memory compression. The other two features, cleancache and > > > > > > frontswap, > > > > > > have been promoted to mainline in 3.0 and 3.5. This patchset > > > > > > promotes zcache from the staging tree to mainline. > > > > > > > > > > > > Based on the level of activity and contributions we're seeing from a > > > > > > diverse set of people and interests, I think zcache has matured to > > > > > > the > > > > > > point where it makes sense to promote this out of staging. > > > > > > > > > > Hi Seth -- > > > > > > > > > > Per offline communication, I'd like to see this delayed for three > > > > > reasons: > > > > > > > > > > 1) I've completely rewritten zcache and will post the rewrite soon. > > > > >The redesigned code fixes many of the weaknesses in zcache that > > > > >makes it (IMHO) unsuitable for an enterprise distro. (Some of > > > > >these previously discussed in linux-mm [1].) > > > > > 2) zcache is truly mm (memory management) code and the fact that > > > > >it is in drivers at all was purely for logistical reasons > > > > >(e.g. the only in-tree "staging" is in the drivers directory). > > > > >My rewrite promotes it to (a subdirectory of) mm where IMHO it > > > > >belongs. > > > > > 3) Ramster heavily duplicates code from zcache. My rewrite resolves > > > > >this. My soon-to-be-post also places the re-factored ramster > > > > >in mm, though with some minor work zcache could go in mm and > > > > >ramster could stay in staging. > > > > > > > > > > Let's have this discussion, but unless the community decides > > > > > otherwise, please consider this a NACK. > > > > > > Hi Konrad -- > > > > > > > Hold on, that is rather unfair. The zcache has been in staging > > > > for quite some time - your code has not been posted. Part of > > > > "unstaging" a driver is for folks to review the code - and you > > > > just said "No, mine is better" without showing your goods. > > > > > > Sorry, I'm not trying to be unfair. However, I don't see the point > > > of promoting zcache out of staging unless it is intended to be used > > > by real users in a real distro. There's been a lot of discussion, > > > onlist and offlist, about what needs to be fixed in zcache and not > > > much visible progress on fixing it. But fixing it is where I've spent > > > most of my time over the last couple of months. > > > > > > If IBM or some other company or distro is eager to ship and support > > > zcache in its current form, I agree that "promote now, improve later" > > > is a fine approach. But promoting zcache out of staging simply because > > > there is urgency to promote zsmalloc+zram out of staging doesn't > > > seem wise. At a minimum, it distracts reviewers/effort from what IMHO > > > is required to turn zcache into an enterprise-ready kernel feature. > > > > > > I can post my "goods" anytime. In its current form it is better > > > than the zcache in staging (and, please remember, I wrote both so > > > I think I am in a good position to compare the two). > > > I have been waiting until I think the new zcache is feature complete > > > before asking for review, especially since the newest features > > > should demonstrate clearly why the rewrite is necessary and > > > beneficial. But I can post* my current bits if people don't > > > believe they exist and/or don't mind reviewing non-final code. > > > (* Or I can put them in a publicly available git tree.) > > > > > > > There is a third option - which is to continue the promotion > > > > of zcache from staging, get reviews, work on them ,etc, and > > > > alongside of that you can work on fixing up (or ripping out) > > > > zcache1 with zcache2 components as they make sense. Or even > > > > having two of them - an enterprise and an embedded version > > > > that will eventually get merged together. There is nothing > > > > wrong with modifying a driver once it has left staging. > > > > > > Minchan and Seth can correct me if I am wrong, but I believe > > > zram+zsmalloc, not zcache, is the target solution for embedded. > > > > NOT ture. Some embedded devices use zcache but it's not original > > zcache but modificated one. > > What kind of modifications? Would it make sense to post the patches It's for contiguos memory allocation. For it, it
Re: [PATCH 1/3] backlight: da9052: Use usleep_range() instead of msleep() for small sleeps
Hi Jingoo,
On 6 August 2012 10:13, Jingoo Han wrote:
> Since msleep might not sleep for the desired amount when less
> than 20ms, use usleep_range.
>
> Cc: Ashish Jangam
> Cc: Richard Purdie
> Signed-off-by: Jingoo Han
> ---
> drivers/video/backlight/da9052_bl.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/backlight/da9052_bl.c
> b/drivers/video/backlight/da9052_bl.c
> index b628d68..10485c9 100644
> --- a/drivers/video/backlight/da9052_bl.c
> +++ b/drivers/video/backlight/da9052_bl.c
> @@ -72,7 +72,7 @@ static int da9052_adjust_wled_brightness(struct da9052_bl
> *wleds)
> if (ret < 0)
> return ret;
>
> - msleep(10);
> + usleep_range(1, 11000);
Can't we just use usleep(1) instead?
>
> if (wleds->brightness) {
> ret = da9052_reg_write(wleds->da9052,
> wled_bank[wleds->led_reg],
> --
> 1.7.1
>
>
> --
> 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/
--
With warm regards,
Sachin
--
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/
[PATCH 2/4] perf tools: Split out util/symbol-elf.c
From: Namhyung Kim
Factor out the dependency of ELF handling into separate symbol-elf.c
file. It is a preparation of building a minimalistic version perf
tools which doesn't depend on the elfutils.
Signed-off-by: Namhyung Kim
---
tools/perf/Makefile | 1 +
tools/perf/util/map.c| 19 +
tools/perf/util/map.h| 1 +
tools/perf/util/symbol-elf.c | 775 +
tools/perf/util/symbol.c | 804 +--
tools/perf/util/symbol.h | 15 +
6 files changed, 818 insertions(+), 797 deletions(-)
create mode 100644 tools/perf/util/symbol-elf.c
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 77f124fe57ad..a25162a858ab 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -354,6 +354,7 @@ LIB_OBJS += $(OUTPUT)util/usage.o
LIB_OBJS += $(OUTPUT)util/wrapper.o
LIB_OBJS += $(OUTPUT)util/sigchain.o
LIB_OBJS += $(OUTPUT)util/symbol.o
+LIB_OBJS += $(OUTPUT)util/symbol-elf.o
LIB_OBJS += $(OUTPUT)util/dso-test-data.o
LIB_OBJS += $(OUTPUT)util/color.o
LIB_OBJS += $(OUTPUT)util/pager.o
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index cc33486ad9e2..115654c469c6 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -86,6 +86,25 @@ out_delete:
return NULL;
}
+/*
+ * Constructor variant for modules (where we know from /proc/modules where
+ * they are loaded) and for vmlinux, where only after we load all the
+ * symbols we'll know where it starts and ends.
+ */
+struct map *map__new2(u64 start, struct dso *dso, enum map_type type)
+{
+ struct map *map = calloc(1, (sizeof(*map) +
+(dso->kernel ? sizeof(struct kmap) : 0)));
+ if (map != NULL) {
+ /*
+* ->end will be filled after we load all the symbols
+*/
+ map__init(map, type, start, 0, 0, dso);
+ }
+
+ return map;
+}
+
void map__delete(struct map *self)
{
free(self);
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index 03a1e9b08b21..1e183d1ae581 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -115,6 +115,7 @@ void map__init(struct map *self, enum map_type type,
struct map *map__new(struct list_head *dsos__list, u64 start, u64 len,
u64 pgoff, u32 pid, char *filename,
enum map_type type);
+struct map *map__new2(u64 start, struct dso *dso, enum map_type type);
void map__delete(struct map *self);
struct map *map__clone(struct map *self);
int map__overlap(struct map *l, struct map *r);
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
new file mode 100644
index ..753e56e7fe93
--- /dev/null
+++ b/tools/perf/util/symbol-elf.c
@@ -0,0 +1,775 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "symbol.h"
+#include "debug.h"
+
+#ifndef NT_GNU_BUILD_ID
+#define NT_GNU_BUILD_ID 3
+#endif
+
+/**
+ * elf_symtab__for_each_symbol - iterate thru all the symbols
+ *
+ * @syms: struct elf_symtab instance to iterate
+ * @idx: uint32_t idx
+ * @sym: GElf_Sym iterator
+ */
+#define elf_symtab__for_each_symbol(syms, nr_syms, idx, sym) \
+ for (idx = 0, gelf_getsym(syms, idx, );\
+idx < nr_syms; \
+idx++, gelf_getsym(syms, idx, ))
+
+static inline uint8_t elf_sym__type(const GElf_Sym *sym)
+{
+ return GELF_ST_TYPE(sym->st_info);
+}
+
+static inline int elf_sym__is_function(const GElf_Sym *sym)
+{
+ return elf_sym__type(sym) == STT_FUNC &&
+ sym->st_name != 0 &&
+ sym->st_shndx != SHN_UNDEF;
+}
+
+static inline bool elf_sym__is_object(const GElf_Sym *sym)
+{
+ return elf_sym__type(sym) == STT_OBJECT &&
+ sym->st_name != 0 &&
+ sym->st_shndx != SHN_UNDEF;
+}
+
+static inline int elf_sym__is_label(const GElf_Sym *sym)
+{
+ return elf_sym__type(sym) == STT_NOTYPE &&
+ sym->st_name != 0 &&
+ sym->st_shndx != SHN_UNDEF &&
+ sym->st_shndx != SHN_ABS;
+}
+
+static bool elf_sym__is_a(GElf_Sym *sym, enum map_type type)
+{
+ switch (type) {
+ case MAP__FUNCTION:
+ return elf_sym__is_function(sym);
+ case MAP__VARIABLE:
+ return elf_sym__is_object(sym);
+ default:
+ return false;
+ }
+}
+
+static inline const char *elf_sym__name(const GElf_Sym *sym,
+ const Elf_Data *symstrs)
+{
+ return symstrs->d_buf + sym->st_name;
+}
+
+static inline const char *elf_sec__name(const GElf_Shdr *shdr,
+ const Elf_Data *secstrs)
+{
+ return secstrs->d_buf + shdr->sh_name;
+}
+
+static inline int elf_sec__is_text(const GElf_Shdr *shdr,
+ const Elf_Data *secstrs)
+{
+ return strstr(elf_sec__name(shdr, secstrs), "text")
[PATCH 4/4] perf symbols: Implement poor man's ELF parser
From: Namhyung Kim
Implement a minimal elf parser for getting build-id. It assumes that
required elf.h header is provided by libc header on the system and the
parser only looks for PT_NOTE program header to check build-id.
Signed-off-by: Namhyung Kim
---
tools/perf/util/symbol-minimal.c | 242 +--
1 file changed, 235 insertions(+), 7 deletions(-)
diff --git a/tools/perf/util/symbol-minimal.c b/tools/perf/util/symbol-minimal.c
index 416ecf3bccf5..bd8720b6780c 100644
--- a/tools/perf/util/symbol-minimal.c
+++ b/tools/perf/util/symbol-minimal.c
@@ -1,15 +1,71 @@
#include "symbol.h"
+#include
+#include
+#include
+#include
+#include
+#include
-int filename__read_build_id(const char *filename __used, void *bf __used,
- size_t size __used)
+
+static bool check_need_swap(int file_endian)
{
- return -1;
+ const int data = 1;
+ u8 *check = (u8 *)
+ int host_endian;
+
+ if (check[0] == 1)
+ host_endian = ELFDATA2LSB;
+ else
+ host_endian = ELFDATA2MSB;
+
+ return host_endian != file_endian;
}
-int sysfs__read_build_id(const char *filename __used, void *build_id __used,
-size_t size __used)
+#define NOTE_ALIGN(sz) (((sz) + 3) & ~3)
+
+#define NT_GNU_BUILD_ID3
+
+static int read_build_id(void *note_data, size_t note_len, void *bf,
+size_t size, bool need_swap)
{
+ struct {
+ u32 n_namesz;
+ u32 n_descsz;
+ u32 n_type;
+ } *nhdr;
+ void *ptr;
+
+ ptr = note_data;
+ while (ptr < (note_data + note_len)) {
+ const char *name;
+ size_t namesz, descsz;
+
+ nhdr = ptr;
+ if (need_swap) {
+ nhdr->n_namesz = bswap_32(nhdr->n_namesz);
+ nhdr->n_descsz = bswap_32(nhdr->n_descsz);
+ nhdr->n_type = bswap_32(nhdr->n_type);
+ }
+
+ namesz = NOTE_ALIGN(nhdr->n_namesz);
+ descsz = NOTE_ALIGN(nhdr->n_descsz);
+
+ ptr += sizeof(*nhdr);
+ name = ptr;
+ ptr += namesz;
+ if (nhdr->n_type == NT_GNU_BUILD_ID &&
+ nhdr->n_namesz == sizeof("GNU")) {
+ if (memcmp(name, "GNU", sizeof("GNU")) == 0) {
+ size_t sz = min(size, descsz);
+ memcpy(bf, ptr, sz);
+ memset(bf + sz, 0, size - sz);
+ return 0;
+ }
+ }
+ ptr += descsz;
+ }
+
return -1;
}
@@ -19,6 +75,172 @@ int filename__read_debuglink(const char *filename __used,
return -1;
}
+/*
+ * Just try PT_NOTE header otherwise fails
+ */
+int filename__read_build_id(const char *filename, void *bf, size_t size)
+{
+ FILE *fp;
+ int ret = -1;
+ bool need_swap = false;
+ u8 e_ident[EI_NIDENT];
+ size_t buf_size;
+ void *buf;
+ int i;
+
+ fp = fopen(filename, "r");
+ if (fp == NULL)
+ return -1;
+
+ if (fread(e_ident, sizeof(e_ident), 1, fp) != 1)
+ goto out;
+
+ if (memcmp(e_ident, ELFMAG, SELFMAG) ||
+ e_ident[EI_VERSION] != EV_CURRENT)
+ goto out;
+
+ need_swap = check_need_swap(e_ident[EI_DATA]);
+
+ /* for simplicity */
+ fseek(fp, 0, SEEK_SET);
+
+ if (e_ident[EI_CLASS] == ELFCLASS32) {
+ Elf32_Ehdr ehdr;
+ Elf32_Phdr *phdr;
+
+ if (fread(, sizeof(ehdr), 1, fp) != 1)
+ goto out;
+
+ if (need_swap) {
+ ehdr.e_phoff = bswap_32(ehdr.e_phoff);
+ ehdr.e_phentsize = bswap_16(ehdr.e_phentsize);
+ ehdr.e_phnum = bswap_16(ehdr.e_phnum);
+ }
+
+ buf_size = ehdr.e_phentsize * ehdr.e_phnum;
+ buf = malloc(buf_size);
+ if (buf == NULL)
+ goto out;
+
+ fseek(fp, ehdr.e_phoff, SEEK_SET);
+ if (fread(buf, buf_size, 1, fp) != 1)
+ goto out_free;
+
+ for (i = 0, phdr = buf; i < ehdr.e_phnum; i++, phdr++) {
+ void *tmp;
+
+ if (need_swap) {
+ phdr->p_type = bswap_32(phdr->p_type);
+ phdr->p_offset = bswap_32(phdr->p_offset);
+ phdr->p_filesz = bswap_32(phdr->p_filesz);
+ }
+
+ if (phdr->p_type != PT_NOTE)
+ continue;
+
+ buf_size = phdr->p_filesz;
+ tmp = realloc(buf, buf_size);
+ if (tmp == NULL)
+
[PATCH 3/3] backlight: kb3886: Use usleep_range() instead of msleep() for small sleeps
Since msleep might not sleep for the desired amount when less than 20ms, use usleep_range. Cc: Claudio Nieder Cc: Richard Purdie Signed-off-by: Jingoo Han --- drivers/video/backlight/kb3886_bl.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/backlight/kb3886_bl.c b/drivers/video/backlight/kb3886_bl.c index 72dd555..6c5ed6b 100644 --- a/drivers/video/backlight/kb3886_bl.c +++ b/drivers/video/backlight/kb3886_bl.c @@ -34,9 +34,9 @@ static void kb3886_bl_set_intensity(int intensity) mutex_lock(_mutex); intensity = intensity&0xff; outb(KB3886_ADC_DAC_PWM, KB3886_PARENT); - msleep(10); + usleep_range(1, 11000); outb(KB3886_PWM0_WRITE, KB3886_IO); - msleep(10); + usleep_range(1, 11000); outb(intensity, KB3886_IO); mutex_unlock(_mutex); } -- 1.7.1 -- 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/
[PATCH 2/3] backlight: ltv350qv: Use usleep_range() instead of msleep() for small sleeps
Since msleep might not sleep for the desired amount when less than 20ms, use usleep_range. Cc: Haavard Skinnemoen Cc: Richard Purdie Signed-off-by: Jingoo Han --- drivers/video/backlight/ltv350qv.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/video/backlight/ltv350qv.c b/drivers/video/backlight/ltv350qv.c index 6c0f1ac..4066a5b 100644 --- a/drivers/video/backlight/ltv350qv.c +++ b/drivers/video/backlight/ltv350qv.c @@ -75,7 +75,7 @@ static int ltv350qv_power_on(struct ltv350qv *lcd) /* Power On Reset Display off State */ if (ltv350qv_write_reg(lcd, LTV_PWRCTL1, 0x)) goto err; - msleep(15); + usleep_range(15000, 16000); /* Power Setting Function 1 */ if (ltv350qv_write_reg(lcd, LTV_PWRCTL1, LTV_VCOM_DISABLE)) @@ -153,7 +153,7 @@ err_settings: err_power2: err_power1: ltv350qv_write_reg(lcd, LTV_PWRCTL2, 0x); - msleep(1); + usleep_range(1000, 1100); err: ltv350qv_write_reg(lcd, LTV_PWRCTL1, LTV_VCOM_DISABLE); return -EIO; @@ -175,7 +175,7 @@ static int ltv350qv_power_off(struct ltv350qv *lcd) ret |= ltv350qv_write_reg(lcd, LTV_PWRCTL2, 0x); /* Wait at least 1 ms */ - msleep(1); + usleep_range(1000, 1100); /* Power down setting 2 */ ret |= ltv350qv_write_reg(lcd, LTV_PWRCTL1, LTV_VCOM_DISABLE); -- 1.7.1 -- 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/
[PATCH 1/3] backlight: da9052: Use usleep_range() instead of msleep() for small sleeps
Since msleep might not sleep for the desired amount when less
than 20ms, use usleep_range.
Cc: Ashish Jangam
Cc: Richard Purdie
Signed-off-by: Jingoo Han
---
drivers/video/backlight/da9052_bl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/backlight/da9052_bl.c
b/drivers/video/backlight/da9052_bl.c
index b628d68..10485c9 100644
--- a/drivers/video/backlight/da9052_bl.c
+++ b/drivers/video/backlight/da9052_bl.c
@@ -72,7 +72,7 @@ static int da9052_adjust_wled_brightness(struct da9052_bl
*wleds)
if (ret < 0)
return ret;
- msleep(10);
+ usleep_range(1, 11000);
if (wleds->brightness) {
ret = da9052_reg_write(wleds->da9052, wled_bank[wleds->led_reg],
--
1.7.1
--
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: [RFC][PATCH] Reset PCIe devices to address DMA problem on kdump with iommu
Hi Vivek,
(2012/08/03 20:46), Vivek Goyal wrote:
> On Fri, Aug 03, 2012 at 08:24:31PM +0900, Takao Indoh wrote:
>> Hi all,
>>
>> This patch adds kernel parameter "reset_pcie_devices" which resets PCIe
>> devices at boot time to address DMA problem on kdump with iommu. When
>> this parameter is specified, a hot reset is triggered on each PCIe root
>> port and downstream port to reset its downstream endpoint.
>
> Hi Takao,
>
> Why not use existing "reset_devices" parameter instead of introducing
> a new one?
"reset_devices" is used for each driver to reset their own device, and
this patch resets all devices forcibly, so I thought they were different
things.
Thanks,
Takao Indoh
>
> Thanks
> Vivek
>
>>
>> Background:
>> A kdump problem about DMA has been discussed for a long time. That is,
>> when a kernel is switched to the kdump kernel DMA derived from first
>> kernel affects second kernel. Recently this problem surfaces when iommu
>> is used for PCI passthrough on KVM guest. In the case of the machine I
>> use, when intel_iommu=on is specified, DMAR error is detected in kdump
>> kernel and PCI SERR is also detected. Finally kdump fails because some
>> devices does not work correctly.
>>
>> The root cause is that ongoing DMA from first kernel causes DMAR fault
>> because page table of DMAR is initialized while kdump kernel is booting
>> up. Therefore to address this problem DMA needs to be stopped before DMAR
>> is initialized at kdump kernel boot time. By this patch, PCIe devices
>> are reset by hot reset and its DMA is stopped when reset_pcie_devices is
>> specified. One problem of this solution is that VGA is reset and the
>> monitor blacks out when the link between the port and VGA controller was
>> reset. So this patch does not reset the port whose child endpoint is VGA
>> device.
>>
>> Any comments would be appreciated.
>>
>> Signed-off-by: Takao Indoh
>> ---
>> Documentation/kernel-parameters.txt |4 +
>> drivers/pci/quirks.c| 59 ++
>> 2 files changed, 63 insertions(+)
>>
>> diff --git a/Documentation/kernel-parameters.txt
>> b/Documentation/kernel-parameters.txt
>> index e714a02..e694e9f 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -2489,6 +2489,10 @@ bytes respectively. Such letter suffixes can also be
>> entirely omitted.
>> reset_devices [KNL] Force drivers to reset the underlying device
>> during initialization.
>>
>> +reset_pcie_devices
>> +[PCIE] Reset PCIe endpoint at boot time by sending a
>> +hot reset to root port and downstream port
>> +
>> resume= [SWSUSP]
>> Specify the partition device for software suspend
>> Format:
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 5155317..7f7fc02 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -32,6 +32,65 @@
>> #include "pci.h"
>>
>> /*
>> + * Reset PCIe endpoint by sending a hot reset to root port and downstream
>> port
>> + */
>> +unsigned int reset_pcie_devices;
>> +EXPORT_SYMBOL(reset_pcie_devices);
>> +static int __init set_reset_pcie_devices(char *str)
>> +{
>> +reset_pcie_devices = 1;
>> +return 1;
>> +}
>> +__setup("reset_pcie_devices", set_reset_pcie_devices);
>> +
>> +static void __devinit quirk_pcie_device_reset(struct pci_dev *dev)
>> +{
>> +struct pci_bus *subordinate;
>> +struct pci_dev *child;
>> +u16 ctrl;
>> +
>> +if (!reset_pcie_devices || !pci_is_pcie(dev) || !dev->subordinate ||
>> +((dev->pcie_type != PCI_EXP_TYPE_ROOT_PORT) &&
>> + (dev->pcie_type != PCI_EXP_TYPE_DOWNSTREAM)))
>> +return;
>> +
>> +subordinate = dev->subordinate;
>> +list_for_each_entry(child, >devices, bus_list) {
>> +if ((child->pcie_type == PCI_EXP_TYPE_UPSTREAM) ||
>> +(child->pcie_type == PCI_EXP_TYPE_PCI_BRIDGE) ||
>> +((child->class >> 16) == PCI_BASE_CLASS_DISPLAY))
>> +/* Don't reset switch, bridge, VGA device */
>> +return;
>> +}
>> +
>> +dev_info(>dev, "Reset Secondary bus\n");
>> +
>> +list_for_each_entry(child, >devices, bus_list) {
>> +dev_info(>dev, "save state\n");
>> +pci_save_state(child);
>> +}
>> +
>> +/* Assert Secondary Bus Reset */
>> +pci_read_config_word(dev, PCI_BRIDGE_CONTROL, );
>> +ctrl |= PCI_BRIDGE_CTL_BUS_RESET;
>> +pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
>> +
>> +msleep(2);
>> +
>> +/* De-assert Secondary Bus Reset */
>> +ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
>> +pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
>> +
>> +msleep(200);
>> +
>> +list_for_each_entry(child, >devices, bus_list) {
>> +dev_info(>dev, "restore state\n");
>> +pci_restore_state(child);
>> +}
>> +}
>>
Re: i915 regression on 3.6-rc1: lid blanks screen
On Sun, 5 Aug 2012, Takashi Iwai wrote:
> At Sat, 4 Aug 2012 10:01:13 -0700 (PDT),
> Hugh Dickins wrote:
> >
> > Sorry to report that with 3.6-rc1, closing and opening the lid on
> > this ThinkPad T420s leaves the screen blank, and I have to reboot.
> >
> > I understand there's also an nVidia graphics device in here,
> > but I have that configured out, preferring to use the i915:
> >
> > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
> > Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA
> > controller])
> > Subsystem: Lenovo Device 21d3
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> > Stepping- SERR- FastB2B- DisINTx+
> > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- > Latency: 0
> > Interrupt: pin A routed to IRQ 41
> > Region 0: Memory at f140 (64-bit, non-prefetchable) [size=4M]
> > Region 2: Memory at e000 (64-bit, prefetchable) [size=256M]
> > Region 4: I/O ports at 5000 [size=64]
> > Expansion ROM at [disabled]
> > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> > Address: fee0100c Data: 41c2
> > Capabilities: [d0] Power Management version 2
> > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> > PME(D0-,D1-,D2-,D3hot-,D3cold-)
> > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> > Capabilities: [a4] PCI Advanced Features
> > AFCap: TP+ FLR+
> > AFCtrl: FLR-
> > AFStatus: TP-
> > Kernel driver in use: i915
> >
> > Bisection led to this commit, and reverting indeed gets my screen back:
> >
> > commit 520c41cf2fa029d1e8b923ac2026f96664f17c4b
> > Author: Daniel Vetter
> > Date: Wed Jul 11 16:27:52 2012 +0200
> >
> > drm/i915/lvds: ditch ->prepare special case
...
>
> Hm, it's surprising.
>
> Could you check whether the counter-part intel_lvds_enable() is
> called? If the prepare callback affects, it must be from the mode
> setting (drm_crtc_helper_set_mode()).
Yes, I put a dump_stack() in both, and intel_lvds_enable() gets called
about 0.28 seconds after the intel_lvds_disable() when I lift the lid;
but with no video display until I revert that commit.
Hugh
>
>
> Takashi
>
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> > b/drivers/gpu/drm/i915/intel_lvds.c
> > index 49f09a8..e05c0d3 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -409,13 +409,7 @@ static void intel_lvds_prepare(struct drm_encoder
> > *encoder)
> > {
> > struct intel_lvds *intel_lvds = to_intel_lvds(encoder);
> >
> > - /*
> > -* Prior to Ironlake, we must disable the pipe if we want to adjust
> > -* the panel fitter. However at all other times we can just reset
> > -* the registers regardless.
> > -*/
> > - if (!HAS_PCH_SPLIT(encoder->dev) && intel_lvds->pfit_dirty)
> > - intel_lvds_disable(intel_lvds);
> > + intel_lvds_disable(intel_lvds);
> > }
> >
> > static void intel_lvds_commit(struct drm_encoder *encoder)
--
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 03/18] perf target: Fix check on buffer size
Hi, David On Sun, 05 Aug 2012 22:14:42 -0600, David Ahern wrote: > On 8/5/12 9:53 PM, Namhyung Kim wrote: >> >> I think this should go to the urgent branch too as the offending patch >> seemed to go to the mainline already. >> > > It was picked up by Ingo today and included in his pull request sent > to Linus. > Oh, I didn't see the mail for some reason. Thanks for pointing it out. Thanks, Namhyung -- 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/
[PATCH] gpu/mfd/usb: Fix USB randconfig problems
Fix config warning: warning: ( ... && DRM_USB) selects USB which has unmet direct dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD) by adding the missing dependency on USB_ARCH_HAS_HCD to DRM_UDL and DRM_USB. This exposes: drivers/video/Kconfig:36:error: recursive dependency detected! drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_UDL drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI drivers/usb/Kconfig:16: symbol USB_ARCH_HAS_OHCI depends on I2C drivers/i2c/Kconfig:5: symbol I2C is selected by FB_DDC drivers/video/Kconfig:86: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/Kconfig:385: symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/Kconfig:373: symbol FB_CYBER2000 depends on FB which is due to drivers/usb/Kconfig: config USB_ARCH_HAS_OHCI ... default y if ARCH_PNX4008 && I2C Fix by dropping I2C from the above dependency; logic is that this is not a platform dependency but a configuration dependency: the _architecture_ still supports USB even is I2C is not selected. This exposes: drivers/video/Kconfig:36:error: recursive dependency detected! drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_UDL drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI drivers/usb/Kconfig:17: symbol USB_ARCH_HAS_OHCI depends on MFD_TC6393XB drivers/mfd/Kconfig:396:symbol MFD_TC6393XB depends on GPIOLIB drivers/gpio/Kconfig:35:symbol GPIOLIB is selected by FB_VIA drivers/video/Kconfig:1560: symbol FB_VIA depends on FB which can be fixed by having MFD_TC6393XB select GPIOLIB instead of depending on it. Signed-off-by: Guenter Roeck --- If anyone has a better idea how to fix this set of problems, please let me know. Also, I'll be happy to split the patch into three parts if that helps to get it integrated. drivers/gpu/drm/Kconfig |1 + drivers/gpu/drm/udl/Kconfig |1 + drivers/mfd/Kconfig |3 ++- drivers/usb/Kconfig |2 +- 4 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 23120c0..90e2808 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -22,6 +22,7 @@ menuconfig DRM config DRM_USB tristate depends on DRM + depends on USB_ARCH_HAS_HCD select USB config DRM_KMS_HELPER diff --git a/drivers/gpu/drm/udl/Kconfig b/drivers/gpu/drm/udl/Kconfig index 0b5e096..56e0bf3 100644 --- a/drivers/gpu/drm/udl/Kconfig +++ b/drivers/gpu/drm/udl/Kconfig @@ -1,6 +1,7 @@ config DRM_UDL tristate "DisplayLink" depends on DRM && EXPERIMENTAL + depends on USB_ARCH_HAS_HCD select DRM_USB select FB_SYS_FILLRECT select FB_SYS_COPYAREA diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index d1facef..b1a1462 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -395,7 +395,8 @@ config MFD_TC6387XB config MFD_TC6393XB bool "Support Toshiba TC6393XB" - depends on GPIOLIB && ARM && HAVE_CLK + depends on ARM && HAVE_CLK + select GPIOLIB select MFD_CORE select MFD_TMIO help diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index a7773a3..7065df6 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -13,7 +13,7 @@ config USB_ARCH_HAS_OHCI default y if PXA3xx default y if ARCH_EP93XX default y if ARCH_AT91 - default y if ARCH_PNX4008 && I2C + default y if ARCH_PNX4008 default y if MFD_TC6393XB default y if ARCH_W90X900 default y if ARCH_DAVINCI_DA8XX -- 1.7.9.7 -- 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/
[PATCH] [media] Add USB dependency for IguanaWorks USB IR Transceiver
This patch fixes the error drivers/usb/core/hub.c:3753: undefined reference to `usb_speed_string' seen in various random configurations. Cc: Sean Young Cc: Mauro Carvalho Chehab Signed-off-by: Guenter Roeck --- drivers/media/rc/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 5180390..8be5763 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -261,6 +261,7 @@ config IR_WINBOND_CIR config IR_IGUANA tristate "IguanaWorks USB IR Transceiver" + depends on USB_ARCH_HAS_HCD depends on RC_CORE select USB ---help--- -- 1.7.9.7 -- 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 03/18] perf target: Fix check on buffer size
On 8/5/12 9:53 PM, Namhyung Kim wrote: I think this should go to the urgent branch too as the offending patch seemed to go to the mainline already. It was picked up by Ingo today and included in his pull request sent to Linus. David -- 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: [RFC][PATCH] Reset PCIe devices to address DMA problem on kdump with iommu
On 08/03/2012 07:24 AM, Takao Indoh wrote:
> Hi all,
>
> This patch adds kernel parameter "reset_pcie_devices" which resets PCIe
> devices at boot time to address DMA problem on kdump with iommu. When
> this parameter is specified, a hot reset is triggered on each PCIe root
> port and downstream port to reset its downstream endpoint.
>
> Background:
> A kdump problem about DMA has been discussed for a long time. That is,
> when a kernel is switched to the kdump kernel DMA derived from first
> kernel affects second kernel. Recently this problem surfaces when iommu
> is used for PCI passthrough on KVM guest. In the case of the machine I
> use, when intel_iommu=on is specified, DMAR error is detected in kdump
> kernel and PCI SERR is also detected. Finally kdump fails because some
> devices does not work correctly.
>
> The root cause is that ongoing DMA from first kernel causes DMAR fault
> because page table of DMAR is initialized while kdump kernel is booting
> up. Therefore to address this problem DMA needs to be stopped before DMAR
> is initialized at kdump kernel boot time. By this patch, PCIe devices
> are reset by hot reset and its DMA is stopped when reset_pcie_devices is
> specified. One problem of this solution is that VGA is reset and the
> monitor blacks out when the link between the port and VGA controller was
> reset. So this patch does not reset the port whose child endpoint is VGA
> device.
>
> Any comments would be appreciated.
>
> Signed-off-by: Takao Indoh
> ---
Have you considered something less disruptive such as clearing the
Master Enable in each endpoint's PCI Command Register ?
That should prevent DMA transactions from endpoints during the kdump and
kexec, and when the driver for the device gets reconfigured,
Master Enable will be set back on, but after the driver has had the
opportunity to do a device-specific reset.
- Don
> Documentation/kernel-parameters.txt |4 +
> drivers/pci/quirks.c| 59 ++
> 2 files changed, 63 insertions(+)
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index e714a02..e694e9f 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2489,6 +2489,10 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
> reset_devices [KNL] Force drivers to reset the underlying device
> during initialization.
>
> + reset_pcie_devices
> + [PCIE] Reset PCIe endpoint at boot time by sending a
> + hot reset to root port and downstream port
> +
> resume= [SWSUSP]
> Specify the partition device for software suspend
> Format:
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 5155317..7f7fc02 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -32,6 +32,65 @@
> #include "pci.h"
>
> /*
> + * Reset PCIe endpoint by sending a hot reset to root port and downstream
> port
> + */
> +unsigned int reset_pcie_devices;
> +EXPORT_SYMBOL(reset_pcie_devices);
> +static int __init set_reset_pcie_devices(char *str)
> +{
> + reset_pcie_devices = 1;
> + return 1;
> +}
> +__setup("reset_pcie_devices", set_reset_pcie_devices);
> +
> +static void __devinit quirk_pcie_device_reset(struct pci_dev *dev)
> +{
> + struct pci_bus *subordinate;
> + struct pci_dev *child;
> + u16 ctrl;
> +
> + if (!reset_pcie_devices || !pci_is_pcie(dev) || !dev->subordinate ||
> + ((dev->pcie_type != PCI_EXP_TYPE_ROOT_PORT)&&
> + (dev->pcie_type != PCI_EXP_TYPE_DOWNSTREAM)))
> + return;
> +
> + subordinate = dev->subordinate;
> + list_for_each_entry(child,>devices, bus_list) {
> + if ((child->pcie_type == PCI_EXP_TYPE_UPSTREAM) ||
> + (child->pcie_type == PCI_EXP_TYPE_PCI_BRIDGE) ||
> + ((child->class>> 16) == PCI_BASE_CLASS_DISPLAY))
> + /* Don't reset switch, bridge, VGA device */
> + return;
> + }
> +
> + dev_info(>dev, "Reset Secondary bus\n");
> +
> + list_for_each_entry(child,>devices, bus_list) {
> + dev_info(>dev, "save state\n");
> + pci_save_state(child);
> + }
> +
> + /* Assert Secondary Bus Reset */
> + pci_read_config_word(dev, PCI_BRIDGE_CONTROL,);
> + ctrl |= PCI_BRIDGE_CTL_BUS_RESET;
> + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
> +
> + msleep(2);
> +
> + /* De-assert Secondary Bus Reset */
> + ctrl&= ~PCI_BRIDGE_CTL_BUS_RESET;
> + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
> +
> + msleep(200);
> +
> + list_for_each_entry(child,>devices, bus_list) {
> + dev_info(>dev, "restore state\n");
> + pci_restore_state(child);
> + }
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_pcie_device_reset);
> +
> +/*
>
linux-next: Tree for Aug 6
Hi all, OK, so the merge window is closed. Time to clean up your trees and then start adding new stuff to them. Changes since 20120803: The cifs tree gained a build failure so I used the version from next-20120803. The acpi tree lost its build failure. The rr tree gained a conflict against the s390 tree. The spi-mb tree gained a build failure so I used the version from next-20120803. The rcu tree gained conflicts against the rr tree and Linus' tree. The tty tree still has its build failures for which I have disabled 2 staging drivers and applied a patch. I have still reverted 3 commits from the signal tree at the request of the arm maintainer. It also gained a conflict against the rcu tree. The akpm tree gained a build failure for which I applied a merge fix I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 193 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (42a579a Merge branches 'timers-urgent-for-linus' and 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Merging kbuild-current/rc-fixes (f8f5701 Linux 3.5-rc1) Merging arm-current/fixes (b74253f ARM: 7479/1: mm: avoid NULL dereference when flushing gate_vma with VIVT caches) Merging m68k-current/for-linus (9e2760d m68k: Make sys_atomic_cmpxchg_32 work on classic m68k) Merging powerpc-merge/merge (ad36cb0 powerpc/kvm/book3s_32: Fix MTMSR_EERI macro) Merging sparc/master (a27032e sparc64: do not clobber personality flags in sys_sparc64_personality()) Merging net/master (d836200 igb: don't break user visible strings over multiple lines in igb_ethtool.c) Merging sound-current/for-linus (fcfb786 ALSA: emu10k1: Avoid access to invalid pages when period=1) Merging pci-current/for-linus (314489b Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging wireless/master (d4e5979 ath9k: Add PID/VID support for AR) Merging driver-core.current/driver-core-linus (0d7614f Linux 3.6-rc1) Merging tty.current/tty-linus (38bd2a1 pch_uart: Fix parity setting issue) Merging usb.current/usb-linus (84a1caf Linux 3.5-rc7) Merging staging.current/staging-linus (6887a41 Linux 3.5-rc5) Merging char-misc.current/char-misc-linus (84a1caf Linux 3.5-rc7) Merging input-current/for-linus (cf45b5a Merge branch 'next' into for-linus) Merging md-current/for-linus (58e94ae md/raid1: close some possible races on write errors during resync) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (76f16f8 crypto: hifn_795x - fix 64bit division and undefined __divdi3 on 32bit archs) Merging ide/master (39a50b4 Merge branch 'hfsplus') Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for
Re: [PATCH 03/18] perf target: Fix check on buffer size
Hi, Arnaldo On Fri, 3 Aug 2012 17:17:03 +0300, Kirill A. Shutemov wrote: > On Fri, Aug 03, 2012 at 11:00:55AM -0300, Arnaldo Carvalho de Melo wrote: >> From: Namhyung Kim >> >> It was a mistake just replace assert to BUG_ON since its condition >> should be negated. Fix it. >> >> Signed-off-by: Namhyung Kim >> Cc: "Kirill A. Shutemov" >> Cc: Ingo Molnar >> Cc: Kirill A. Shutemov >> Cc: Paul Mackerras >> Cc: Peter Zijlstra >> Cc: Ulrich Drepper >> Link: >> http://lkml.kernel.org/r/1343267410-7758-1-git-send-email-namhy...@kernel.org >> Signed-off-by: Arnaldo Carvalho de Melo > > Acked-by: Kirill A. Shutemov I think this should go to the urgent branch too as the offending patch seemed to go to the mainline already. Thanks, Namhyung -- 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/
linux-next: build failure after merge of the akpm tree
Hi Andrew,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) failed like this:
fs/gfs2/rgrp.c: In function 'gfs2_rs_alloc':
fs/gfs2/rgrp.c:456:2: error: implicit declaration of function 'rb_init_node'
[-Werror=implicit-function-declaration]
Caused by commit 5599fe1ab023 ("rbtree: empty nodes have no color") from
the akpm tree interacting with commit cde7c325077b ("GFS2: Add structure
to contain rgrp, bitmap, offset tuple") from the gfs2 tree.
I have applied the following merge fix patch (which is probably not
sufficient).
From: Stephen Rothwell
Date: Mon, 6 Aug 2012 13:35:11 +1000
Subject: [PATCH] rbtree/gfs2: remove call to rb_init_node
Signed-off-by: Stephen Rothwell
---
fs/gfs2/rgrp.c |2 --
1 file changed, 2 deletions(-)
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index 06476b3..6fb3a57 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -453,8 +453,6 @@ int gfs2_rs_alloc(struct gfs2_inode *ip)
if (!res)
error = -ENOMEM;
- rb_init_node(>rs_node);
-
down_write(>i_rw_mutex);
if (ip->i_res)
kmem_cache_free(gfs2_rsrv_cachep, res);
@@ -486,7 +484,6 @@ static void __rs_deltree(struct gfs2_inode *ip, struct
gfs2_blkreserv *rs)
rgd = rs->rs_rbm.rgd;
trace_gfs2_rs(ip, rs, TRACE_RS_TREEDEL);
rb_erase(>rs_node, >rd_rstree);
- rb_init_node(>rs_node);
BUG_ON(!rgd->rd_rs_cnt);
rgd->rd_rs_cnt--;
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpLZVzuvPKXM.pgp
Description: PGP signature
Re: [PATCH TRIVIAL] mm: Fix build warning in kmem_cache_create()
On Mon, 2012-07-30 at 13:18 +0300, Pekka Enberg wrote: > On Sat, Jul 14, 2012 at 2:12 AM, Shuah Khan wrote: > > The label oops is used in CONFIG_DEBUG_VM ifdef block and is defined > > outside ifdef CONFIG_DEBUG_VM block. This results in the following > > build warning when built with CONFIG_DEBUG_VM disabled. Fix to move > > label oops definition to inside a CONFIG_DEBUG_VM block. > > > > mm/slab_common.c: In function ‘kmem_cache_create’: > > mm/slab_common.c:101:1: warning: label ‘oops’ defined but not used > > [-Wunused-label] > > > > Signed-off-by: Shuah Khan > > I merged this as an obvious and safe fix for current merge window. We > need to clean this up properly for v3.7. Thanks for merging the obvious fix. I was on vacation for the last two weeks, and just got back. I sent another patch that restructures the debug and non-debug code right before I went on vacation. Didn't get a chance to look at the responses (if any). Will get working on following up and re-working and re-sending the patch as needed this week. -- Shuah -- 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 5/6] drivers/char/tlclk.c: fix error return code
Acked-by
--mark
Ps sorry for the outlook munged reply.
-Original Message-
From: Julia Lawall [mailto:julia.law...@lip6.fr]
Sent: Sunday, August 05, 2012 2:53 AM
To: Gross, Mark
Cc: kernel-janit...@vger.kernel.org; Arnd Bergmann; Greg Kroah-Hartman;
linux-kernel@vger.kernel.org; Julia Lawall
Subject: [PATCH 5/6] drivers/char/tlclk.c: fix error return code
From: Julia Lawall
Convert a 0 error return code to a negative one, as returned elsewhere in the
function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret;
expression e,e1,e2,e3,e4,x;
@@
(
if (\(ret != 0\|ret < 0\) || ...) { ... return ...; }
|
ret = 0
)
... when != ret = e1
*x =
\(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...);
... when != x = e2
when != ret = e3
*if (x == NULL || ...)
{
... when != ret = e4
* return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/char/tlclk.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tlclk.c b/drivers/char/tlclk.c index ce29e7c..e95e0ab
100644
--- a/drivers/char/tlclk.c
+++ b/drivers/char/tlclk.c
@@ -784,8 +784,10 @@ static int __init tlclk_init(void)
}
tlclk_major = ret;
alarm_events = kzalloc( sizeof(struct tlclk_alarms), GFP_KERNEL);
- if (!alarm_events)
+ if (!alarm_events) {
+ ret = -ENOMEM;
goto out1;
+ }
/* Read telecom clock IRQ number (Set by BIOS) */
if (!request_region(TLCLK_BASE, 8, "telco_clock")) {
--
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] Documentation/filesystems/porting: Update documentation.
On 08/03/2012 12:34 PM, Sachidananda Urs wrote: > ->get_sb() is no longer used, update documentation to use ->mount(). Also > added > a example for struct file_system_type. > > Signed-off-by: Sachidananda Urs Acked-by: Rob Landley (Yesterday at Texas Linuxfest I _finally_ got some of the gpg signatures to resurrect my kernel.org account, but I'll forward this through -trivial in the meantime unless somebody else picks it up first.) Thanks, Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. -- 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/1]hid:hid-multitouch: add mt_resume for ELAN's production
Mode change to 0644.
From: Scott Liu
Signed-off-by: Scott Liu
---
0 files changed
mode change 100755 => 100644 drivers/hid/hid-ids.h
mode change 100755 => 100644 drivers/hid/hid-multitouch.c
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
old mode 100755
new mode 100644
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
old mode 100755
new mode 100644
--
1.7.9.5
-Original Message-
From: linux-input-ow...@vger.kernel.org
[mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Jian-Jhong Ding
Sent: Friday, August 03, 2012 5:58 PM
To: 劉嘉駿; 'benjamin.tissoires'; 'Dmitry Torokhov'; 'Jiri Kosina'
Cc: linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org;
elegh...@gmail.com
Subject: Re: [PATCH 1/1]hid:hid-multitouch: add mt_resume for ELAN's
production
Hi Scott,
劉嘉駿 writes:
> Some of ELAN’s production need to issue set_idle when resume.
>
> Signed-off-by: Scott Liu
You might want to add a From: line at the top of mail body to make your
name go along with the SoB line.
> ---
> drivers/hid/hid-ids.h|3 +++
> drivers/hid/hid-multitouch.c | 27 +++
> 2 files changed, 30 insertions(+)
> mode change 100644 => 100755 drivers/hid/hid-ids.h
> mode change 100644 => 100755 drivers/hid/hid-multitouch.c
I believe these two files are merely plain text source file. No need to
make them executives.
And, please consider using git send-mail to send the patches. Your MTA
is still making the indent pretty ugly.
Thanks,
-JJ
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> old mode 100644
> new mode 100755
> index 41c34f2..703aaed
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -829,4 +829,7 @@
> #define USB_VENDOR_ID_PRIMAX 0x0461
> #define USB_DEVICE_ID_PRIMAX_KEYBOARD 0x4e05
>
> +#define USB_VENDOR_ID_ELAN 0x04f3
> +#define USB_DEVICE_ID_ELAN_MOCCA 0x000a
> +
> #endif
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> old mode 100644
> new mode 100755
> index 59c8b5c..2c898bb
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -767,6 +767,32 @@ static int mt_reset_resume(struct hid_device *hdev)
>mt_set_input_mode(hdev);
>return 0;
> }
> +
> +static int mt_resume(struct hid_device *hdev)
> +{
> + struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
> + struct usb_host_interface *interface = intf->cur_altsetting;
> +
> + struct usb_device *dev = hid_to_usb_dev(hdev);
> +
> +
> + if (hdev->vendor == USB_VENDOR_ID_ELAN &&
> + hdev->product == USB_DEVICE_ID_ELAN_MOCCA) {
> +
> + usb_control_msg(dev,
> + usb_sndctrlpipe(dev, 0),
> + HID_REQ_SET_IDLE,
> + USB_TYPE_CLASS |
USB_RECIP_INTERFACE,
> + 0,
> + interface->desc.bInterfaceNumber,
> + NULL,
> + 0,
> + USB_CTRL_SET_TIMEOUT);
> + }
> +
> + return 0;
> +}
> +
> #endif
>
> static void mt_remove(struct hid_device *hdev)
> @@ -1092,6 +1118,7 @@ static struct hid_driver mt_driver = {
>.event = mt_event,
> #ifdef CONFIG_PM
>.reset_resume = mt_reset_resume,
> + .resume=mt_resume,
> #endif
> };
>
> --
> 1.7.9.5
>
> --
> 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/
linux-next: manual merge of the signal tree with the rcu tree
Hi Al,
Today's linux-next merge of the signal tree got a conflict in
arch/x86/kernel/signal.c between commit 1ea856be75ce ("x86: Exit RCU
extended QS on notify resume") from the rcu tree and commit 02bf6b04fcd5
("x86: switch uses of TIF_IRET to TIF_NOTIFY_RESUME, kill TIF_IRET") from
the signal tree.
Just context changes. I have fixed it up (see below) and can carry the
fix as necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/kernel/signal.c
index bca0ab9,16f61c4..000
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@@ -802,12 -797,6 +802,8 @@@ do_notify_resume(struct pt_regs *regs,
}
if (thread_info_flags & _TIF_USER_RETURN_NOTIFY)
fire_user_return_notifiers();
+
- #ifdef CONFIG_X86_32
- clear_thread_flag(TIF_IRET);
- #endif /* CONFIG_X86_32 */
-
+ rcu_user_enter();
}
void signal_fault(struct pt_regs *regs, void __user *frame, char *where)
pgp3gasV8rbIr.pgp
Description: PGP signature
Re: [PATCH 4/5] [RFC][HACK] Add LRU_VOLATILE support to the VM
Hi John, On Fri, Jul 27, 2012 at 11:57:11PM -0400, John Stultz wrote: > In an attempt to push the volatile range managment even > deeper into the VM code, this is my first attempt at > implementing Minchan's idea of a LRU_VOLATILE list in > the mm core. > > This list sits along side the LRU_ACTIVE_ANON, _INACTIVE_ANON, > _ACTIVE_FILE, _INACTIVE_FILE and _UNEVICTABLE lru lists. > > When a range is marked volatile, the pages in that range > are moved to the LRU_VOLATILE list. Since volatile pages > can be quickly purged, this list is the first list we > shrink when we need to free memory. > > When a page is marked non-volatile, it is moved from the > LRU_VOLATILE list to the appropriate LRU_ACTIVE_ list. I think active list promotion is not good. It should go to the inactive list and they get a chance to activate from inactive to active sooner or later if it is really touched. > > This patch introduces the LRU_VOLATILE list, an isvolatile > page flag, functions to mark and unmark a single page > as volatile, and shrinker functions to purge volatile > pages. > > This is a very raw first pass, and is neither performant > or likely bugfree. It works in my trivial testing, but > I've not pushed it very hard yet. > > I wanted to send it out just to get some inital thoughts > on the approach and any suggestions should I be going too > far in the wrong direction. I look at this series and found several nitpicks about implemenataion but I think it's not a good stage about concerning it. Although naming is rather differet with I suggested, I think it's good idea. So let's talk about it firstly. I will call VOLATILE list as EReclaimale LRU list. The purpose of it is that prevent unnecessary LRU churning and reclaim unnecessary pages fastly so that latency-sensitive system don't have a big latency when memory pressure happens. Targets for the LRU list could be following as in future 1. volatile pages in this patchset. 2. ephemeral pages of tmem 3. madivse(DONTNEED) 4. fadvise(NOREUSE) 5. PG_reclaimed pages 6. clean pages if we write CFLRU(clean first LRU) So if any guys have objection, please raise your hands before further progress. > > CC: Andrew Morton > CC: Android Kernel Team > CC: Robert Love > CC: Mel Gorman > CC: Hugh Dickins > CC: Dave Hansen > CC: Rik van Riel > CC: Dmitry Adamushko > CC: Dave Chinner > CC: Neil Brown > CC: Andrea Righi > CC: Aneesh Kumar K.V > CC: Mike Hommey > CC: Jan Kara > CC: KOSAKI Motohiro > CC: Michel Lespinasse > CC: Minchan Kim > CC: linux...@kvack.org > Signed-off-by: John Stultz > --- > include/linux/fs.h |1 + > include/linux/mm_inline.h |2 ++ > include/linux/mmzone.h |1 + > include/linux/page-flags.h |3 ++ > include/linux/swap.h |3 ++ > mm/memcontrol.c|1 + > mm/page_alloc.c|1 + > mm/swap.c | 71 + > mm/vmscan.c| 76 > +--- > 9 files changed, 155 insertions(+), 4 deletions(-) > -- Kind regards, Minchan Kim -- 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] Extcon: adc_jack: adc-jack driver to support 3.5 pi or simliar devices
On Mon, 2012-08-06 at 02:15 +, 함명주 wrote: > > From: anish kumar > > > > External connector devices that decides connection information based on > > ADC values may use adc-jack device driver. The user simply needs to > > provide a table of adc range and connection states. Then, extcon > > framework will automatically notify others. > > > > Signed-off-by: anish kumar > > - Please remove "get_adc" callbacks still remaining in the header file > (and its comments) aha.Forgot to remove this. > > - Let's not modify un-related driver code (in Kconfig, extcon-gpio) I think this was unintended(my mistake).Sending the patch again. > > Except that, things look good. > > > Cheers > MyungJoo > > -- 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/4] x86, CPU: Fixup tlb_flushall_shift formatting
On 08/04/2012 12:37 AM, Borislav Petkov wrote: > From: Borislav Petkov > > The TLB characteristics appeared like this in dmesg: > > [0.065817] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512 > [0.065817] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512 > [0.065817] tlb_flushall_shift is 0x > > where tlb_flushall_shift is actually -1 but dumped as a hex number. > However, the Kconfig option CONFIG_DEBUG_TLBFLUSH and the rest of the > code treats this as a signed decimal and states "If you set it to -1, > the code flushes the whole TLB unconditionally." > > So, fix its formatting in accordance with the other references to it. > > Signed-off-by: Borislav Petkov Acked-by Alex Shi -- 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 09/22] ARM: LPAE: use 64-bit pgd physical address in switch_mm()
On Sun, 5 Aug 2012, Cyril Chemparathy wrote: > On 8/4/2012 3:04 AM, Nicolas Pitre wrote: > > On Tue, 31 Jul 2012, Cyril Chemparathy wrote: > > > > > This patch modifies the switch_mm() processor functions to use 64-bit > > > addresses. We use u64 instead of phys_addr_t, in order to avoid having > > > config > > > dependent register usage when calling into switch_mm assembly code. > > > > > > The changes in this patch are primarily adjustments for registers used for > > > arguments to switch_mm. The few processor definitions that did use the > > > second > > > argument have been modified accordingly. > > > > > > Arguments and calling conventions aside, this patch should be a no-op on > > > v6 > > > and non-LPAE v7 processors. > > > > NAK. > > > > You just broke all big endian targets, LPAE or not. > > > > Indeed. Thanks. > > Would C-land word swappery on BE do? Any other ideas on the best approach to > this? First, don't use a u64 unconditionally. A phys_addr_t is best for the same arguments as before. Since this is equivalent to a u64 only when LPAE is defined, you then only have to care about endian issues in proc-v7-3level.S. And in there you can deal with the issue with register aliases just as it is done in lib/div64.S. Nicolas -- 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/
linux-next: manual merge of the rcu tree with Linus' tree
Hi Paul,
Today's linux-next merge of the rcu tree got a conflict in
include/linux/sched.h between commit 907aed48f65e ("mm: allow PF_MEMALLOC
from softirq context") from Linus' tree and commit 46fc4e7c01b7 ("rcu:
Switch task's syscall hooks on context switch") from the rcu tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/linux/sched.h
index b8c8664,a094959..000
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@@ -1886,13 -1879,14 +1886,21 @@@ static inline void rcu_copy_process(str
#endif
+static inline void tsk_restore_flags(struct task_struct *task,
+ unsigned long orig_flags, unsigned long flags)
+{
+ task->flags &= ~flags;
+ task->flags |= orig_flags & flags;
+}
+
+ static inline void rcu_switch(struct task_struct *prev,
+ struct task_struct *next)
+ {
+ #ifdef CONFIG_RCU_USER_QS
+ rcu_user_hooks_switch(prev, next);
+ #endif
+ }
+
#ifdef CONFIG_SMP
extern void do_set_cpus_allowed(struct task_struct *p,
const struct cpumask *new_mask);
pgphxu3tUAmBM.pgp
Description: PGP signature
linux-next: manual merge of the rcu tree with the rr tree
Hi Paul,
Today's linux-next merge of the rcu tree got a conflict in arch/Kconfig
arch/x86/Kconfig between commit d673c23ca730 ("Make most arch
asm/module.h files use asm-generic/module.h") from the rr tree and commits
3dbdfc26e27f ("rcu: Settle config for userspace extended quiescent
state") and 1ea856be75ce ("x86: Exit RCU extended QS on notify resume")
from the rcu tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/Kconfig
index 3450115,1c7c9be..000
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@@ -281,23 -274,14 +281,33 @@@ config SECCOMP_FILTE
See Documentation/prctl/seccomp_filter.txt for details.
+config HAVE_MOD_ARCH_SPECIFIC
+ bool
+ help
+The arch uses struct mod_arch_specific to store data. Many arches
+just need a simple module loader without arch specific data - those
+should not enable this.
+
+config MODULES_USE_ELF_RELA
+ bool
+ help
+Modules only use ELF RELA relocations. Modules with ELF REL
+relocations will give an error.
+
+config MODULES_USE_ELF_REL
+ bool
+ help
+Modules only use ELF REL relocations. Modules with ELF RELA
+relocations will give an error.
+
+ config HAVE_RCU_USER_QS
+ bool
+ help
+ Provide kernel entry/exit hooks necessary for userspace
+ RCU extended quiescent state. Syscalls need to be wrapped inside
+ rcu_user_exit()-rcu_user_enter() through the slow path using
+ TIF_NOHZ flag. Exceptions handlers must be wrapped as well. Irqs
+ are already protected inside rcu_irq_enter/rcu_irq_exit() but
+ preemption or signal handling on irq exit still need to be protected.
+
source "kernel/gcov/Kconfig"
diff --cc arch/x86/Kconfig
index a00d899,38dfcc2..000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -97,8 -95,7 +97,9 @@@ config X8
select KTIME_SCALAR if X86_32
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
+ select MODULES_USE_ELF_REL if X86_32
+ select MODULES_USE_ELF_RELA if X86_64
+ select HAVE_RCU_USER_QS if X86_64
config INSTRUCTION_DECODER
def_bool (KPROBES || PERF_EVENTS || UPROBES)
pgpkt4zcYB9PA.pgp
Description: PGP signature
Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
On 08/04/2012 11:12 PM, Mark Brown wrote:
On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
I missed some of the earlier bits of the thread here but why can't we do
device based lookups?
That is because the phandles would not be properties of the device
node but rather of its sub-nodes:
backlight {
compatible = "pwm-backlight";
...
power-on-sequence {
step@0 {
regulator = <_reg>;
enable;
};
So here simply using regulator_get on the backlight device would not work.
Ah, right. DT isn't being terribly helpful here... I think the thing
I'd expect to work here is that you have a reference back to the supply
property of the backlight device rather than direct to the regulator so
you end up writing "enable supply X" rather than "enable regulator X".
Not quite sure how exactly you'd accomplish that - I guess if
regulator_get() would recursively follow phandles until it hits a node
that'd do the trick?
Do you mean that regulator_get() would parse sub-nodes looking for a
match? That seems rather dangerous and error-prone, especially if one
has actual devices within the sub-nodes - their regulators could be
stolen by the parent device.
I think we only have two choices for this:
1) Stick to the scheme where resources are declared at the device level,
such as they can be referenced by name in the sub-nodes (basically what
I did in this patch):
backlight {
compatible = "pwm-backlight";
...
backlight-supply = <_reg>;
power-on-sequence {
step@0 {
regulator = "backlight";
enable;
};
This would translate by a get_regulator(dev, "backlight") in the code
which would be properly resolved.
2) Export a lower-level DT API for resolving phandles directly from a
property, similar to of_get_named_gpio. We would then have
of_get_named_regulator and of_get_named_pwm.
If 2) is deemed acceptable, then I think we should go for it as it would
provide the most compact and readable DT syntax. Otherwise 1) is still
acceptable IMHO, as it should at least make sense to people already
familiar with how the DT works.
Opinions from DT experts?
Alex.
--
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 04/22] ARM: LPAE: support 64-bit virt/phys patching
On Sun, 5 Aug 2012, Cyril Chemparathy wrote: > Hi Nicolas, > > On 8/4/2012 2:49 AM, Nicolas Pitre wrote: > > On Tue, 31 Jul 2012, Cyril Chemparathy wrote: > > > > > This patch adds support for 64-bit physical addresses in virt_to_phys > > > patching. This does not do real 64-bit add/sub, but instead patches in > > > the > > > upper 32-bits of the phys_offset directly into the output of virt_to_phys. > > > > You should explain _why_ you do not a real aadd/sub. I did deduce it > > but that might not be obvious to everyone. Also this subtlety should be > > commented in the code as well. > > > > We could not do an ADDS + ADC here because the carry is not guaranteed to be > retained and passed into the ADC. This is because the compiler is free to > insert all kinds of stuff between the two non-volatile asm blocks. > > Is there another subtlety here that I have missed out on entirely? The high bits for the valid physical memory address range for which virt_to_phys and phys_to_virt can be used are always the same. Therefore no aadition at all is needed, fake or real. Only providing those bits in the top word for the value returned by virt_to_phys is needed. > > > In addition to adding 64-bit support, this patch also adds a > > > set_phys_offset() > > > helper that is needed on architectures that need to modify PHYS_OFFSET > > > during > > > initialization. > > > > > > Signed-off-by: Cyril Chemparathy > > > --- > > > arch/arm/include/asm/memory.h | 22 +++--- > > > arch/arm/kernel/head.S|6 ++ > > > arch/arm/kernel/setup.c | 14 ++ > > > 3 files changed, 35 insertions(+), 7 deletions(-) > > > > > > diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h > > > index 4a0108f..110495c 100644 > > > --- a/arch/arm/include/asm/memory.h > > > +++ b/arch/arm/include/asm/memory.h > > > @@ -153,23 +153,31 @@ > > > #ifdef CONFIG_ARM_PATCH_PHYS_VIRT > > > > > > extern unsigned long __pv_phys_offset; > > > -#define PHYS_OFFSET __pv_phys_offset > > > - > > > +extern unsigned long __pv_phys_offset_high; > > > > As mentioned previously, this is just too ugly. Please make > > __pv_phys_offset into a phys_addr_t instead and mask the low/high parts > > as needed in __virt_to_phys(). > > > > Maybe u64 instead of phys_addr_t to keep the sizing non-variable? No. When not using LPAE, we don't have to pay the price of a u64 value. That's why the phys_addr_t type is conditionally defined. You already do extra processing in virt_to_phys when sizeof(phys_addr_t) > 4 which is perfect for dealing with this issue. Nicolas -- 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: DT GPIO numbering?
On 08/05/2012 04:06 AM, Linus Walleij wrote: > On Wed, Aug 1, 2012 at 5:22 PM, Johannes Stezenbach wrote: > >> I'm currently learning how Linux devicetree support works, >> here is one question I couldn't find an answer for. >> >> I understand that within the devicetree GPIOs are referenced by phandle, >> thus the numbers are irrelevant. However, in sysfs the number is >> what is used to access the GPIO, e.g. for debugging or >> blinkenlight apps. How does this fit together? > > I think it simply does not fit together. > > Grant & me has been claiming the GPIO sysfs interface is a bit > crazy from time to time. > > My long-term plan would be to replace it with /dev/gpio/gpioN > device nodes per-gpiochip and use ioctl etc to control these > beasts instead. However one does not do that overnight, > and my life is too busy, and other refactorings also need to > happen :-/ I can't comment on the sysfs-vs-dev interface location, but I don't think it addresses Johannes' issue; finding out which GPIO IDs are provided by which devices. Perhaps in each device's sysfs node, there should be some information re: which GPIO range it provides. Right now, perhaps a text file with the GPIO base it it. With the new /dev interface you mention above, perhaps a symlink to the /dev file, or a file containing the /dev file's major/minor number. Or, is there such a thing already (other than debugfs's gpio file). -- 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]: Mac80211
Hi Christopher, On Mon, Aug 6, 2012 at 12:02 PM, Christopher Sacchi wrote: > The source file needed a change that was told in the description to > know that the #include needed to be fixed, and the function changed > another value to 0 (yes) in the description (that said FIXME.) This still doesn't explain everything. I'm guessing that the changes you're making fix some bug you've seen. Your patch description, which should be in the *same* email as the correctly formatted patch itself needs to tell us what bug this fixes, including any error messages that appear, and do so clearly and sensibly so that the maintainer (Johannes) can quickly and easily evaluate whether this patch is worth accepting. You also need to format it correctly so that if he decides to accept it, he can import it directly using git. To do that, you need to send a *single* email that contains the description and the patch, following the rules here: https://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=blob;f=Documentation/SubmittingPatches;h=c379a2a6949f1c1cac04fb6f185c633512f37061;hb=HEAD Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/ -- 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 6/9] rbtree: low level optimizations in rb_erase()
On 08/02/2012 06:34 PM, Michel Lespinasse wrote: Various minor optimizations in rb_erase(): - Avoid multiple loading of node->__rb_parent_color when computing parent and color information (possibly not in close sequence, as there might be further branches in the algorithm) - In the 1-child subcase of case 1, copy the __rb_parent_color field from the erased node to the child instead of recomputing it from the desired parent and color - When searching for the erased node's successor, differentiate between cases 2 and 3 based on whether any left links were followed. This avoids a condition later down. - In case 3, keep a pointer to the erased node's right child so we don't have to refetch it later to adjust its parent. - In the no-childs subcase of cases 2 and 3, place the rebalance assigment last so that the compiler can remove the following if(rebalance) test. Also, added some comments to illustrate cases 2 and 3. Signed-off-by: Michel Lespinasse Acked-by: Rik van Riel -- All rights reversed -- 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] Extcon: adc_jack: adc-jack driver to support 3.5 pi or simliar devices
> From: anish kumar > > External connector devices that decides connection information based on > ADC values may use adc-jack device driver. The user simply needs to > provide a table of adc range and connection states. Then, extcon > framework will automatically notify others. > > Signed-off-by: anish kumar - Please remove "get_adc" callbacks still remaining in the header file (and its comments) - Let's not modify un-related driver code (in Kconfig, extcon-gpio) Except that, things look good. Cheers MyungJoo
Re: [PATCH v2 9/9] rbtree: remove prior augmented rbtree implementation
On 08/02/2012 06:34 PM, Michel Lespinasse wrote: convert arch/x86/mm/pat_rbtree.c to the proposed augmented rbtree api and remove the old augmented rbtree implementation. Signed-off-by: Michel Lespinasse Acked-by: Rik van Riel -- All rights reversed -- 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 8/9] rbtree: faster augmented rbtree manipulation
On 08/02/2012 06:34 PM, Michel Lespinasse wrote: Introduce new augmented rbtree APIs that allow minimal recalculation of augmented node information. A new callback is added to the rbtree insertion and erase rebalancing functions, to be called on each tree rotations. Such rotations preserve the subtree's root augmented value, but require recalculation of the one child that was previously located at the subtree root. In the insertion case, the handcoded search phase must be updated to maintain the augmented information on insertion, and then the rbtree coloring/rebalancing algorithms keep it up to date. In the erase case, things are more complicated since it is library code that manipulates the rbtree in order to remove internal nodes. This requires a couple additional callbacks to copy a subtree's augmented value when a new root is stitched in, and to recompute augmented values down the ancestry path when a node is removed from the tree. In order to preserve maximum speed for the non-augmented case, we provide two versions of each tree manipulation function. rb_insert_augmented() is the augmented equivalent of rb_insert_color(), and rb_erase_augmented() is the augmented equivalent of rb_erase(). Signed-off-by: Michel Lespinasse Acked-by: Rik van Riel -- All rights reversed -- 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 7/9] rbtree: augmented rbtree test
On 08/02/2012 06:34 PM, Michel Lespinasse wrote: Small test to measure the performance of augmented rbtrees. Signed-off-by: Michel Lespinasse Acked-by: Rik van Riel -- All rights reversed -- 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/
Oops in loop_clr_fd => bd_set_size
I got an Oops from running "losetup -d /dev/loop2". The trace shows loop_clr_fd calling bd_set_size, and the parameter bdev appears to have a NULL in its bd_disk field. The losetup command was run as part of a script that did this: losetup -d /dev/loop5 losetup -d /dev/loop4 losetup -d /dev/loop3 losetup -d /dev/loop2 losetup -d /dev/loop1 The kernel was processing a lot of loop_clr_fd's in a quick sequence. The first three worked, and the loop2 Oopsed. After that I ran the losetup -d /dev/loop1 separately and it worked. The process that caused the Oops didn't die: PID TTY STAT TIME COMMAND 5055 pts/1D 0:00 [losetup] I also tried to query the current state of the device with "losetup loop2" after the Oops. That gave me a second stuck process: PID TTY STAT TIME COMMAND 5059 pts/1D+ 0:00 losetup /dev/loop2 These processes are still alive, in their permanent D state. The rest of the system is still functional. I'll try to keep it that way for now, in case anyone wants to suggest some debugging actions that I can take. The loop devices were set up to handle an unusual situation: I have a whole hard drive image contained within a partition on another hard drive. Each loop device corresponds to a partition of the imaged drive. They were set up like this, with numbers taken from its partition table: cyl=516096 losetup -o $((1*$cyl)) --sizelimit $(((2080-1+1)*$cyl)) /dev/loop1 /dev/sda6 losetup -o $((2081*$cyl)) --sizelimit $(((4160-2081+1)*$cyl)) /dev/loop2 /dev/sda6 losetup -o $((4161*$cyl)) --sizelimit $(((24965-4161+1)*$cyl)) /dev/loop3 /dev/sda6 losetup -o $((24966*$cyl)) --sizelimit $(((45770-24966+1)*$cyl)) /dev/loop4 /dev/sda6 losetup -o $((45771*$cyl)) --sizelimit $(((158815-45771+1)*$cyl)) /dev/loop5 /dev/sda6 So all the loop devices were referencing the same backing device, with different (adjacent but non-overlapping) offsets. I had also done blockdev --setro on sda6 and all of the loop devices as soon as they were created. The devices were successfully dm_snapshot'ed, fscked, mounted, and all data was copied off of them before I did the losetup -d that caused the oops. The one that failed, loop2, actually corresponded to the swap partition of the imaged drive so I didn't copy anything off of it, but I know it was working because I used "strings /dev/loop2" to figure out what it was. That's all the information I can think of that might be relevant. I'm willing to dig deeper if there's anything that can be retrieved from the two stuck processes, or I could reboot and try to repeat the incident. Here is the Oops: BUG: unable to handle kernel NULL pointer dereference at 0328 IP: [] bd_set_size+0x7/0x5e PGD 156eb067 PUD 102aa067 PMD 0 Oops: [#1] SMP CPU 1 Modules linked in: dm_snapshot ext3 jbd ext2 snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc arc4 carl9170 ehci_hcd mac80211 usbcore usb_common led_class ath cfg80211 rfkill sha256_generic aes_x86_64 aes_generic cbc crc32c_intel loop dm_crypt dm_mod sd_mod crc_t10dif ata_piix libata scsi_mod Pid: 5055, comm: losetup Not tainted 3.5.0 #17 BIOSTAR Group TH61 ITX/TH61 ITX RIP: 0010:[] [] bd_set_size+0x7/0x5e RSP: 0018:88001113ddd0 EFLAGS: 00010246 RAX: RBX: 8800721b4a00 RCX: 000180240011 RDX: 000180240012 RSI: RDI: 880100385d40 RBP: 880100385d40 R08: 880072dcb8c0 R09: 000180240011 R10: 80240011 R11: R12: 880073712300 R13: 00020010 R14: 8800721b4b14 R15: FS: 7f98183ba700() GS:88010030() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0328 CR3: 1adcb000 CR4: 000407e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process losetup (pid: 5055, threadinfo 88001113c000, task 8800732c8640) Stack: a00b251c 8800721b4a00 8800739ec9c0 4c01 8800721b4b30 a00b315d 880072209c20 88000f9f6900 7f9817f09430 001d 880031878840 Call Trace: [] ? loop_clr_fd+0x154/0x1f5 [loop] [] ? lo_ioctl+0x4af/0x657 [loop] [] ? blkdev_ioctl+0x632/0x666 [] ? block_ioctl+0x32/0x36 [] ? do_vfs_ioctl+0x44b/0x490 [] ? virt_to_head_page+0x9/0x2c [] ? kmem_cache_free+0x12/0x9e [] ? sys_ioctl+0x3c/0x5f [] ? system_call_fastpath+0x16/0x1b Code: 20 31 c0 48 85 c9 75 1b 48 39 7f 70 74 13 48 8b 46 50 48 3d ba ff 10 81 74 07 48 85 c0 0f 94 c0 c3 b0 01 c3 48 8b 87 90 00 00 00 <48> 8b 80 28 03 00 00 48 85 c0 74 0e 8b 90 d0 04 00 00 66 85 d2 RIP [] bd_set_size+0x7/0x5e RSP CR2: 0328 ---[ end trace 149557d36d01641b ]--- -- Alan Curry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the
Re: [PATCH 0/4] Remove Genesi Efika MX support
On Wed, Aug 01, 2012 at 12:49:27PM -0500, Matt Sealey wrote: > In an effort to start afresh we are removing the "legacy" Efika MX support > from the tree in this patch series so as to break ties with any > non-device-tree > code and minimize the possibility that there are two ways to build for our > boards. > > Patches to support the board again with FDT (along with a matching U-Boot) > are not ready for submission, but that doesn't block *this* submission. The > number of users of 3.5 kernels on Genesi platforms is generally thought of > as zero and no significant work or support has been committed to the platform > in a long time. In our opinion, all efforts by external developers wishing to > run modern kernels on Genesi Efika MX boards should be directed at device tree > support for the MX51 platforms. > > Matt Sealey (4): > efikamx: remove support for Genesi Efika MX from the build > efikamx: remove Genesi Efika MX from the i.MX v6/v7 defconfig > efikamx: remove Genesi Efika MX platform files from the tree > efikamx: remove Efika MX-specific CHRGVBUS hack from the USB driver > > arch/arm/configs/imx_v6_v7_defconfig |2 - > arch/arm/mach-imx/Kconfig | 26 -- > arch/arm/mach-imx/Makefile|3 - > arch/arm/mach-imx/efika.h | 10 - > arch/arm/mach-imx/mach-mx51_efikamx.c | 300 > arch/arm/mach-imx/mach-mx51_efikasb.c | 296 --- > arch/arm/mach-imx/mx51_efika.c| 632 > - > drivers/usb/host/ehci-mxc.c | 20 -- > 8 files changed, 1289 deletions(-) > delete mode 100644 arch/arm/mach-imx/efika.h > delete mode 100644 arch/arm/mach-imx/mach-mx51_efikamx.c > delete mode 100644 arch/arm/mach-imx/mach-mx51_efikasb.c > delete mode 100644 arch/arm/mach-imx/mx51_efika.c > I set up a branch imx/rm-boards and queued the series there. I expect I will have some patches removing imx53 board files to be queued there for 3.7 too. -- Regards, Shawn -- 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 02/22] ARM: use late patch framework for phys-virt patching
On Sun, 5 Aug 2012, Cyril Chemparathy wrote: > Hi Nicolas, > > On 8/4/2012 2:15 AM, Nicolas Pitre wrote: > > On Tue, 31 Jul 2012, Cyril Chemparathy wrote: > > > > > This patch replaces the original physical offset patching implementation > > > with one that uses the newly added patching framework. In the process, we > > > now > > > unconditionally initialize the __pv_phys_offset and __pv_offset globals in > > > the > > > head.S code. > > > > Why unconditionally initializing those? There is no reason for that. > > > > We could keep this conditional on LPAE, but do you see any specific need for > keeping it conditional? This has nothing to do with LPAe. This is about CONFIG_ARM_PATCH_PHYS_VIRT only. If not selected, those global vaariables have no need to exist. > > Comments below. > > > > > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S > > > index 835898e..d165896 100644 > > > --- a/arch/arm/kernel/head.S > > > +++ b/arch/arm/kernel/head.S > > [...] > > > .data > > > .globl __pv_phys_offset > > > .type __pv_phys_offset, %object > > > __pv_phys_offset: > > > .long 0 > > > .size __pv_phys_offset, . - __pv_phys_offset > > > + > > > + .globl __pv_offset > > > + .type __pv_offset, %object > > > __pv_offset: > > > .long 0 > > > -#endif > > > + .size __pv_offset, . - __pv_offset > > > > Please move those to C code. They aren't of much use in this file > > anymore. This will allow you to use pphys_addr_t for them as well in > > your subsequent patch. And more importantly get rid of that ugly > > pv_offset_high that you introduced iin another patch. > > > > Moving it to C-code caused problems because these get filled in prior to BSS > being cleared. > > We could potentially have this initialized in C with a mystery dummy value to > prevent it from landing in BSS. Would that be acceptable? Just initialize them explicitly to zero. They will end up in .ddata section. > > > > index df5e897..39f8fce 100644 > > > --- a/arch/arm/kernel/module.c > > > +++ b/arch/arm/kernel/module.c > > > @@ -317,11 +317,6 @@ int module_finalize(const Elf32_Ehdr *hdr, const > > > Elf_Shdr *sechdrs, > > > > > > maps[i].txt_sec->sh_addr, > > > > > > maps[i].txt_sec->sh_size); > > > #endif > > > -#ifdef CONFIG_ARM_PATCH_PHYS_VIRT > > > - s = find_mod_section(hdr, sechdrs, ".pv_table"); > > > - if (s) > > > - fixup_pv_table((void *)s->sh_addr, s->sh_size); > > > -#endif > > > s = find_mod_section(hdr, sechdrs, ".patch.table"); > > > if (s) > > > patch_kernel((void *)s->sh_addr, s->sh_size); > > > > The patch_kernel code and its invokation should still be conditional on > > CONFIG_ARM_PATCH_PHYS_VIRT. This ability may still be configured out > > irrespective of the implementation used. > > > > Maybe CONFIG_ARM_PATCH_PHYS_VIRT is not quite appropriate if this is used to > patch up other things in addition to phys-virt stuff? Maybe, but at the moment this is not the case. > I could have this dependent on CONFIG_ARM_INIT_PATCH (or whatever nomenclature > we chose for this) and have CONFIG_ARM_PATCH_PHYS_VIRT depend on it. Let's cross that bridge in time. FWIW, I don't like "init patch" much. I feel like the "runtime" qualifier more pricisely describe this code than "init". Nicolas -- 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/
linux-next: build failure after merge of the spi-mb tree
Hi Mark,
After merging the spi-mb tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/spi/spi-gpio.c: In function 'spi_gpio_setup':
drivers/spi/spi-gpio.c:255:8: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
Caused by casting a pointer to "unsigned int" in commit a38e7a71f120
("spi: spi-gpio: Add DT bindings").
drivers/spi/spi-gpio.c: In function 'spi_probe_dt':
drivers/spi/spi-gpio.c:389:39: error: parameter name omitted
drivers/spi/spi-gpio.c: In function 'spi_gpio_probe':
drivers/spi/spi-gpio.c:404:2: error: implicit declaration of function
'spi_gpio_probe_dt' [-Werror=implicit-function-declaration]
Caused by commit a38e7a71f120 ("spi: spi-gpio: Add DT bindings"). This
build does not have CONFIG_OF set.
I have used the spi-mb tree from next-20120803 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpchdDZhzXN9.pgp
Description: PGP signature
[PATCH]: Mac80211
The source file needed a change that was told in the description to know that the #include needed to be fixed, and the function changed another value to 0 (yes) in the description (that said FIXME.) Thanks, -- Christopher -- 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]: Mac80211 Driver patch
On 08/05/2012 06:52 PM, Christopher Sacchi wrote: > Patch for Mac80211, and no this is not spam, so do not ignore my > e-mails. This is a patch, so copy this into your favorite text editor > and save it as test.patch. Let the maintainers read and know! By the > way, it is under the first -- line and to the 2nd to last line. :) > -- You won't need to say where the patch is if you will read and follow Documentation/SubmittingPatches . > --- main.c2012-07-21 20:58:29.0 + > +++ mainnew.c 2012-08-05 20:00:37.0 + > @@ -32,7 +32,7 @@ > #include "led.h" > #include "cfg.h" > #include "debugfs.h" > - > +#include "net/rfkill/rfkill.h" > static struct lock_class_key ieee80211_rx_skb_queue_class; > > void ieee80211_configure_filter(struct ieee80211_local *local) > @@ -183,6 +183,7 @@ >* >*/ > /* WARN_ON(ret); */ > + WARN_ON(1) Does that build without a problem? or is it missing a ';' ?? > } > > return ret; > -- -- ~Randy -- 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: linux-next: build failure after merge of the cifs tree
On Sun, Aug 5, 2012 at 7:48 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the cifs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/cifs/Kconfig:3: syntax error
> fs/Kconfig:244: missing end statement for this entry
>
> Caused by commit 12f3f9b7c80c ("Remove sparse warning in cifsfs.c").
> Please, please build test after doing updates and before publishing your
> tree.
>
> I have used the cifs tree from next-20120803 for today.
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
Fixed. The corrupted commit came after a build test caught a few
sparse warnings - forgot to rerun the build test though after fixing
the warning (I had multiple
Kconfigs I build test - fs/cifs/Kconfig obviously should not have changed)
--
Thanks,
Steve
--
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]: Mac80211 Driver patch
Hi Christopher, On Mon, Aug 6, 2012 at 11:52 AM, Christopher Sacchi wrote: > Patch for Mac80211, and no this is not spam, so do not ignore my > e-mails. This is a patch, so copy this into your favorite text editor > and save it as test.patch. Let the maintainers read and know! By the > way, it is under the first -- line and to the 2nd to last line. :) Again, this is not how you submit patches. Please read my previous email. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/ -- 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]: With no attatchment NOT SPAM, a REWRITE
Hi Christopher, On Mon, Aug 6, 2012 at 11:01 AM, Christopher Sacchi wrote: > Hey guys, this should work now. I see the changes you made, however you're not going to get them accepted in this format. See Documentation/SubmittingPatches Online here: https://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=blob;f=Documentation/SubmittingPatches;h=c379a2a6949f1c1cac04fb6f185c633512f37061;hb=HEAD > -- > --- main.c 2012-07-21 20:58:29.0 + > +++ mainnew.c 2012-08-05 20:00:37.0 + > @@ -32,7 +32,7 @@ > #include "led.h" > #include "cfg.h" > #include "debugfs.h" > - Why are you removing the blank line - it's required as part of the kernel coding style. > +#include "net/rfkill/rfkill.h" You don't seem to actually be adding any code that uses anything in this header and don't explain why it's needed. > static struct lock_class_key ieee80211_rx_skb_queue_class; > > void ieee80211_configure_filter(struct ieee80211_local *local) > @@ -183,6 +183,7 @@ > * > */ > /* WARN_ON(ret); */ > + WARN_ON(1) What bug is this fixing? What problem is this solving? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/ -- 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/
[PATCH]: Mac80211 Driver patch
Patch for Mac80211, and no this is not spam, so do not ignore my e-mails. This is a patch, so copy this into your favorite text editor and save it as test.patch. Let the maintainers read and know! By the way, it is under the first -- line and to the 2nd to last line. :) -- --- main.c 2012-07-21 20:58:29.0 + +++ mainnew.c 2012-08-05 20:00:37.0 + @@ -32,7 +32,7 @@ #include "led.h" #include "cfg.h" #include "debugfs.h" - +#include "net/rfkill/rfkill.h" static struct lock_class_key ieee80211_rx_skb_queue_class; void ieee80211_configure_filter(struct ieee80211_local *local) @@ -183,6 +183,7 @@ * */ /* WARN_ON(ret); */ + WARN_ON(1) } return ret; -- -- Christopher -- 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: Emulating level IRQs
On Mon, Aug 6, 2012 at 1:56 AM, Daniel Mack wrote: > On 05.08.2012 18:56, Haojian Zhuang wrote: >> On Mon, Aug 6, 2012 at 12:22 AM, Daniel Mack wrote: >>> On 24.07.2012 20:01, Daniel Mack wrote: On 23.07.2012 18:51, Dmitry Torokhov wrote: > On Thu, Jul 19, 2012 at 05:36:12PM +0200, Daniel Mack wrote: >> Ok, finally I found some time. In general, the patch works fine. The >> only detail I had to amend was the irqflags, which were changed from >> IRQF_TRIGGER_RISING/IRQF_TRIGGER_FALLING to >> IRQF_TRIGGER_HIGH/IRQF_TRIGGER_LOW, which doesn't work as the PXA can't >> deal with level-based IRQs. Changing this back to RISING/FALLING makes >> the driver work again. > > Hmm, but that would mean we need to restore reading the data in open() > to make sure we re-arm IRQ in case somebody touched the screen before it > was opened by userspace... I had another look at this and don't really know what to do here. We definitely need level interrupts for this device as the interrupt line's level is the only that tells us when we can stop reading from the device. So it's not just the start condition that bites us here. I copied some people that might help find a solution. To summarize the problem: The EETI touchscreen is a device that asserts a GPIO line when it has events to deliver and waits for I2C commands to empty its buffers. When there are no more buffered events, it will de-assert the line. This device is connected to a PXA GPIO that is only able to deliver edge IRQs, and the old implemenation was to wait for an interrupt and then read data as long as the IRQ's corresponding GPIO was asserted. However, expecting that an IRQ is mappable to a GPIO is not something we should do, so the only clean solution is to teach the PXA GPIO controller level IRQs. So it boils down to the question: Is there any easy and generic way to emulate level irq on chips that don't support that natively? >>> >>> Otherwise, we would need some sort of generic irq_to_gpio() again, and >>> the interrupt line the driver listens to must have support for that sort >>> of mapping. >>> >>> Any opinion on this, anyone? >>> >> Since you're using gpio as input, you need to call gpio_request() and set it >> as input direction. And you could also transfer the gpio number into touch >> driver via platform data. Is it OK for you? > > No, that's not the point. What we get via the i2c runtime data is an > interrupt number. The driver is driven by that interrupt and doesn't > poll on a GPIO line, which is how it should be. > > However, in order to know when to stop reading from the device, we need > to monitor the GPIO line after the interrupt has arrived, and read as > long as the line is asserted. Then we stop reading and wait for the next > interrupt to arrive. > > Hence, what we need here is either a GPIO/IRQ controller that is able to > handle level-IRQs (which the PXA can't do), or we need to have a generic > way to map IRQ lines back to GPIOs. > > Of course, I could pass the GPIO in the platform data and the IRQ in the > I2C data and leave it to the user of the driver to keep both values in > sync, but I wanted to avoid that. I see no better way except to encode the GPIO line into the platform data. In order to solve the sync issue, I personally think mapping the GPIO to IRQ would be better here, and ignore the irq value from the I2C data. A forward mapping of gpio_to_irq() will be less problematic here, and for those platforms where gpio_to_irq() returns invalid, those platforms are probably not desirable for this chip. So my understanding, if it's correct, that we can treat the EETI chip as having two separate inputs: one IRQ line (for the event notification) and one GPIO line (for a condition where data are emptied), we could naturally have two numbers in the driver, but unfortunately they end up being in sync as they are physically one pin. And Daniel, I haven't looked into the driver myself, I guess you might need to change the pin role to GPIO with GPIO API explicitly at run-time, e.g. gpio_direction_input() followed by gpio_get_value(), but I believe you should have already done that good enough as always :-) -- 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/
[PATCH] autofs4 - fix get_next_positive_subdir()
From: Ian Kent
Following a report of a crash during an automount expire I found that
the locking in fs/autofs4/expire.c:get_next_positive_subdir() was wrong.
Not only is the locking wrong but the function is more complex than it
needs to be.
The function is meant to calculate (and dget) the next entry in the list
of directories contained in the root of an autofs mount point (an autofs
indirect mount to be precise). The main problem was that the d_lock of
the owner of the list was not being taken when walking the list, which
lead to list corruption under load. The only other lock that needs to
be taken is against the next dentry candidate so it can be checked for
usability.
Signed-off-by: Ian Kent
---
fs/autofs4/expire.c | 31 +--
1 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
index 1feb68e..8c0e56d 100644
--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -94,25 +94,21 @@ static struct dentry *get_next_positive_subdir(struct
dentry *prev,
{
struct autofs_sb_info *sbi = autofs4_sbi(root->d_sb);
struct list_head *next;
- struct dentry *p, *q;
+ struct dentry *q;
spin_lock(>lookup_lock);
+ spin_lock(>d_lock);
- if (prev == NULL) {
- spin_lock(>d_lock);
+ if (prev)
+ next = prev->d_u.d_child.next;
+ else {
prev = dget_dlock(root);
next = prev->d_subdirs.next;
- p = prev;
- goto start;
}
- p = prev;
- spin_lock(>d_lock);
-again:
- next = p->d_u.d_child.next;
-start:
+cont:
if (next == >d_subdirs) {
- spin_unlock(>d_lock);
+ spin_unlock(>d_lock);
spin_unlock(>lookup_lock);
dput(prev);
return NULL;
@@ -121,16 +117,15 @@ start:
q = list_entry(next, struct dentry, d_u.d_child);
spin_lock_nested(>d_lock, DENTRY_D_LOCK_NESTED);
- /* Negative dentry - try next */
- if (!simple_positive(q)) {
- spin_unlock(>d_lock);
- lock_set_subclass(>d_lock.dep_map, 0, _RET_IP_);
- p = q;
- goto again;
+ /* Already gone or negative dentry (under construction) - try next */
+ if (q->d_count == 0 || !simple_positive(q)) {
+ spin_unlock(>d_lock);
+ next = q->d_u.d_child.next;
+ goto cont;
}
dget_dlock(q);
spin_unlock(>d_lock);
- spin_unlock(>d_lock);
+ spin_unlock(>d_lock);
spin_unlock(>lookup_lock);
dput(prev);
--
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/
[BUGFIX -v2 1/4] PCI/PM: enable D3/D3cold by default for most devices
This patch fixes the following bug: http://marc.info/?l=linux-usb=134318961120825=2 Originally, device lower power states include D1, D2, D3. After that, D3 is further divided into D3hot and D3cold. To support both scenario safely, original D3 is mapped to D3cold. When adding D3cold support, because worry about some device may have broken D3cold support, D3cold is disabled by default. This disable D3 on original platform too. But some original platform may only have working D3, but no working D1, D2. The root cause of the above bug is it too. To deal with this, this patch enables D3/D3cold by default for most devices. This restores the original behavior. For some devices that suspected to have broken D3cold support, such as PCIe port, D3cold is disabled by default. Reported-by: Bjorn Mork Signed-off-by: Huang Ying Reviewed-by: Rafael J. Wysocki --- drivers/pci/pci.c |1 + drivers/pci/pcie/portdrv_pci.c |5 + 2 files changed, 6 insertions(+) --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1941,6 +1941,7 @@ void pci_pm_init(struct pci_dev *dev) dev->pm_cap = pm; dev->d3_delay = PCI_PM_D3_WAIT; dev->d3cold_delay = PCI_PM_D3COLD_WAIT; + dev->d3cold_allowed = true; dev->d1_support = false; dev->d2_support = false; --- a/drivers/pci/pcie/portdrv_pci.c +++ b/drivers/pci/pcie/portdrv_pci.c @@ -200,6 +200,11 @@ static int __devinit pcie_portdrv_probe( return status; pci_save_state(dev); + /* +* D3cold may not work properly on some PCIe port, so disable +* it by default. +*/ + dev->d3cold_allowed = false; if (!pci_match_id(port_runtime_pm_black_list, dev)) pm_runtime_put_noidle(>dev); -- 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/
[BUGFIX -v2 3/4] PCI/PM: Fix config reg access for D3cold and bridge suspending
This patch fixes the following bug:
http://marc.info/?l=linux-pci=134338059022620=2
Where lspci does not work properly if a device and the corresponding
parent bridge (such as PCIe port) is suspended. This is because the
device configuration space registers will be not accessible if the
corresponding parent bridge is suspended or the device is put into
D3cold state.
To solve the issue, the bridge/PCIe port connected to the device is
put into active state before read/write configuration space registers.
If the device is in D3cold state, it will be put into active state
too.
To avoid resume/suspend PCIe port for each configuration register
read/write, a small delay is added before the PCIe port to go
suspended.
Reported-by: Bjorn Mork
Signed-off-by: Huang Ying
---
drivers/pci/pci-sysfs.c| 37 +
drivers/pci/pcie/portdrv_pci.c |9 +
2 files changed, 46 insertions(+)
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -458,6 +458,35 @@ boot_vga_show(struct device *dev, struct
}
struct device_attribute vga_attr = __ATTR_RO(boot_vga);
+static void
+pci_config_pm_runtime_get(struct pci_dev *pdev)
+{
+ struct device *dev = >dev;
+ struct device *parent = dev->parent;
+
+ if (parent)
+ pm_runtime_get_sync(parent);
+ pm_runtime_get_noresume(dev);
+ /*
+* pdev->current_state is set to PCI_D3cold during suspending,
+* so wait until suspending completes
+*/
+ pm_runtime_barrier(dev);
+ if (pdev->current_state == PCI_D3cold)
+ pm_runtime_resume(dev);
+}
+
+static void
+pci_config_pm_runtime_put(struct pci_dev *pdev)
+{
+ struct device *dev = >dev;
+ struct device *parent = dev->parent;
+
+ pm_runtime_put(dev);
+ if (parent)
+ pm_runtime_put_sync(parent);
+}
+
static ssize_t
pci_read_config(struct file *filp, struct kobject *kobj,
struct bin_attribute *bin_attr,
@@ -484,6 +513,8 @@ pci_read_config(struct file *filp, struc
size = count;
}
+ pci_config_pm_runtime_get(dev);
+
if ((off & 1) && size) {
u8 val;
pci_user_read_config_byte(dev, off, );
@@ -529,6 +560,8 @@ pci_read_config(struct file *filp, struc
--size;
}
+ pci_config_pm_runtime_put(dev);
+
return count;
}
@@ -549,6 +582,8 @@ pci_write_config(struct file* filp, stru
count = size;
}
+ pci_config_pm_runtime_get(dev);
+
if ((off & 1) && size) {
pci_user_write_config_byte(dev, off, data[off - init_off]);
off++;
@@ -587,6 +622,8 @@ pci_write_config(struct file* filp, stru
--size;
}
+ pci_config_pm_runtime_put(dev);
+
return count;
}
--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -140,9 +140,17 @@ static int pcie_port_runtime_resume(stru
{
return 0;
}
+
+static int pcie_port_runtime_idle(struct device *dev)
+{
+ /* Delay for a short while to prevent too frequent suspend/resume */
+ pm_schedule_suspend(dev, 10);
+ return -EBUSY;
+}
#else
#define pcie_port_runtime_suspend NULL
#define pcie_port_runtime_resume NULL
+#define pcie_port_runtime_idle NULL
#endif
static const struct dev_pm_ops pcie_portdrv_pm_ops = {
@@ -155,6 +163,7 @@ static const struct dev_pm_ops pcie_port
.resume_noirq = pcie_port_resume_noirq,
.runtime_suspend = pcie_port_runtime_suspend,
.runtime_resume = pcie_port_runtime_resume,
+ .runtime_idle = pcie_port_runtime_idle,
};
#define PCIE_PORTDRV_PM_OPS(_portdrv_pm_ops)
--
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/
[PATCH -v2 0/4] PCI/PM: PCI D3cold support fixes for 3.6-rc1
Changes: v2: - Change some pm_runtime_put to pm_runtime_put_sync per Alan and Rafael's comments. [BUGFIX -v2 1/4] PCI/PM: enable D3/D3cold by default for most devices [BUGFIX -v2 2/4] PCI/PM: Keep parent bridge active when probing device [BUGFIX -v2 3/4] PCI/PM: Fix config reg access for D3cold and bridge suspending [PATCH -v2 4/4] PCI/PM: Add ABI document for sysfs file d3cold_allowed -- 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/
[BUGFIX -v2 2/4] PCI/PM: Keep parent bridge active when probing device
This patch fixes the following bug:
http://marc.info/?l=linux-pci=134329923124234=2
The root cause of the bug is as follow.
If a device is not bound with the corresponding driver, the device
runtime PM will be disabled and the device will be put into suspended
state. So that, the bridge/PCIe port connected to it may be put into
suspended and low power state. When do probing for the device later,
because the bridge/PCIe port connected to it is in low power state,
the IO access to device may fail.
To solve the issue, the bridge/PCIe port connected to the device is
put into active state before probing.
Reported-by: Bjorn Mork
Signed-off-by: Huang Ying
Reviewed-by: Rafael J. Wysocki
---
drivers/pci/pci-driver.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -280,8 +280,12 @@ static long local_pci_probe(void *_ddi)
{
struct drv_dev_and_id *ddi = _ddi;
struct device *dev = >dev->dev;
+ struct device *parent = dev->parent;
int rc;
+ /* The parent bridge must be in active state when probing */
+ if (parent)
+ pm_runtime_get_sync(parent);
/* Unbound PCI devices are always set to disabled and suspended.
* During probe, the device is set to enabled and active and the
* usage count is incremented. If the driver supports runtime PM,
@@ -298,6 +302,8 @@ static long local_pci_probe(void *_ddi)
pm_runtime_set_suspended(dev);
pm_runtime_put_noidle(dev);
}
+ if (parent)
+ pm_runtime_put(parent);
return rc;
}
--
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/
[PATCH -v2 4/4] PCI/PM: Add ABI document for sysfs file d3cold_allowed
This patch adds ABI document for the following sysfs file: /sys/bus/pci/devices/.../d3cold_allowed Signed-off-by: Huang Ying Acked-by: Rafael J. Wysocki --- Documentation/ABI/testing/sysfs-bus-pci | 12 1 file changed, 12 insertions(+) --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -210,3 +210,15 @@ Users: firmware assigned instance number of the PCI device that can help in understanding the firmware intended order of the PCI device. + +What: /sys/bus/pci/devices/.../d3cold_allowed +Date: July 2012 +Contact: Huang Ying +Description: + d3cold_allowed is bit to control whether the corresponding PCI + device can be put into D3Cold state. If it is cleared, the + device will never be put into D3Cold state. If it is set, the + device may be put into D3Cold state if other requirements are + satisfied too. Reading this attribute will show the current + value of d3cold_allowed bit. Writing this attribute will set + the value of d3cold_allowed bit. -- 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 5/9] rbtree: handle 1-child recoloring in rb_erase() instead of rb_erase_color()
On 08/02/2012 06:34 PM, Michel Lespinasse wrote: An interesting observation for rb_erase() is that when a node has exactly one child, the node must be black and the child must be red. An interesting consequence is that removing such a node can be done by simply replacing it with its child and making the child black, which we can do efficiently in rb_erase(). __rb_erase_color() then only needs to handle the no-childs case and can be modified accordingly. Signed-off-by: Michel Lespinasse Acked-by: Rik van Riel -- All rights reversed -- 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/
linux-next: manual merge of the rr tree with the s390 tree
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in
arch/s390/Kconfig between commit 867c2dcb369b ("s390/seccomp: add support
for system call filtering using BPF") from the s390 tree and commit
d673c23ca730 ("Make most arch asm/module.h files use
asm-generic/module.h") from the rr tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/s390/Kconfig
index 107610e,11cc724..000
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@@ -124,7 -123,8 +124,9 @@@ config S39
select GENERIC_TIME_VSYSCALL
select GENERIC_CLOCKEVENTS
select KTIME_SCALAR if 32BIT
+ select HAVE_ARCH_SECCOMP_FILTER
+ select HAVE_MOD_ARCH_SPECIFIC
+ select MODULES_USE_ELF_RELA
config SCHED_OMIT_FRAME_POINTER
def_bool y
pgp3e8D1lZi44.pgp
Description: PGP signature
Re: [PATCH 5/6] drivers/video/backlight/da9052_bl.c: drop devm_kfree of devm_kzalloc'd data
On Sunday, August 05, 2012 1:51 AM Julia Lawall wrote:
>
> From: Julia Lawall
>
> devm_kfree should not have to be explicitly used.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> expression x,d;
> @@
>
> x = devm_kzalloc(...)
> ...
> ?-devm_kfree(d,x);
> //
>
> Signed-off-by: Julia Lawall
Acked-by: Jingoo Han
It looks good.
Best regard,
Jingoo Han
>
> ---
> drivers/video/backlight/da9052_bl.c |2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/backlight/da9052_bl.c
> b/drivers/video/backlight/da9052_bl.c
> index b628d68..7c8626a 100644
> --- a/drivers/video/backlight/da9052_bl.c
> +++ b/drivers/video/backlight/da9052_bl.c
> @@ -129,7 +129,6 @@ static int da9052_backlight_probe(struct platform_device
> *pdev)
> _backlight_ops, );
> if (IS_ERR(bl)) {
> dev_err(>dev, "Failed to register backlight\n");
> - devm_kfree(>dev, wleds);
> return PTR_ERR(bl);
> }
>
> @@ -149,7 +148,6 @@ static int da9052_backlight_remove(struct platform_device
> *pdev)
> wleds->state = DA9052_WLEDS_OFF;
> da9052_adjust_wled_brightness(wleds);
> backlight_device_unregister(bl);
> - devm_kfree(>dev, wleds);
>
> return 0;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 4/9] rbtree: place easiest case first in rb_erase()
On 08/02/2012 06:34 PM, Michel Lespinasse wrote: In rb_erase, move the easy case (node to erase has no more than 1 child) first. I feel the code reads easier that way. Signed-off-by: Michel Lespinasse Reviewed-by: Rik van Riel -- All rights reversed -- 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] PM / Sleep: Print name of wakeup source that aborts suspend
On Sun, 5 Aug 2012, Rafael J. Wysocki wrote: > > v2 > > use ktime_to_ns() instead of comparisons on .tv64 field What is the reason for this? It apparently adds complexity and code (on non-64-bit systems) to no purpose. Alan Stern -- 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] m68k: Correct the Atari ALLOWINT definition
On Fri, 2012-08-03 at 23:21 +0200, Geert Uytterhoeven wrote: > From: Mikael Pettersson > > commit c663600584a596b5e66258cc10716fb781a5c2c9 upstream. > > Booting a 3.2, 3.3, or 3.4-rc4 kernel on an Atari using the > `nfeth' ethernet device triggers a WARN_ONCE() in generic irq > handling code on the first irq for that device: [...] Added to the queue for 3.2, thanks. Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part
[PATCH]: With no attatchment NOT SPAM, a REWRITE
Hey guys, this should work now. -- --- main.c 2012-07-21 20:58:29.0 + +++ mainnew.c 2012-08-05 20:00:37.0 + @@ -32,7 +32,7 @@ #include "led.h" #include "cfg.h" #include "debugfs.h" - +#include "net/rfkill/rfkill.h" static struct lock_class_key ieee80211_rx_skb_queue_class; void ieee80211_configure_filter(struct ieee80211_local *local) @@ -183,6 +183,7 @@ * */ /* WARN_ON(ret); */ + WARN_ON(1) } return ret; -- Thanks, -- Christopher P.S. Copy betwwen the two dashed lines. -- 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 3/9] rbtree: add __rb_change_child() helper function
On 08/02/2012 06:34 PM, Michel Lespinasse wrote: Add __rb_change_child() as an inline helper function to replace code that would otherwise be duplicated 4 times in the source. No changes to binary size or speed. Signed-off-by: Michel Lespinasse Reviewed-by: Rik van Riel -- All rights reversed -- 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/
linux-next: build failure after merge of the cifs tree
Hi all,
After merging the cifs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/cifs/Kconfig:3: syntax error
fs/Kconfig:244: missing end statement for this entry
fs/Kconfig:5: missing end statement for this entry
fs/cifs/Kconfig:2: invalid statement
fs/cifs/Kconfig:3: unexpected option "depends"
fs/cifs/Kconfig:4: unexpected option "select"
fs/cifs/Kconfig:5: unexpected option "select"
fs/cifs/Kconfig:6: unexpected option "select"
fs/cifs/Kconfig:7: unexpected option "select"
fs/cifs/Kconfig:8: unexpected option "select"
fs/cifs/Kconfig:9: unexpected option "select"
fs/cifs/Kconfig:10: unexpected option "select"
fs/cifs/Kconfig:11: unexpected option "select"
fs/cifs/Kconfig:12: unexpected option "select"
fs/cifs/Kconfig:13: invalid statement
fs/cifs/Kconfig:14: unknown statement "This"
fs/cifs/Kconfig:15: unknown statement "CIFS"
fs/cifs/Kconfig:16: unknown statement "SMB"
fs/cifs/Kconfig:17: unknown statement "PC"
fs/cifs/Kconfig:18: unknown statement "file"
fs/cifs/Kconfig:19: unknown statement "and"
fs/cifs/Kconfig:20: unknown statement "server"
fs/cifs/Kconfig:21: unknown statement "support"
fs/cifs/Kconfig:22: unknown statement "well"
fs/cifs/Kconfig:25: syntax error
fs/cifs/Kconfig:24: unknown statement "The"
fs/cifs/Kconfig:25: unknown statement "client"
fs/cifs/Kconfig:26: unknown statement "support"
fs/cifs/Kconfig:27: unknown statement "session"
fs/cifs/Kconfig:28: unknown statement "safe"
fs/cifs/Kconfig:29: unknown statement "signing"
fs/cifs/Kconfig:30: unknown statement "If"
fs/Kconfig:274: unexpected end statement
fs/Kconfig:279: unexpected end statement
Caused by commit 12f3f9b7c80c ("Remove sparse warning in cifsfs.c").
Please, please build test after doing updates and before publishing your
tree.
I have used the cifs tree from next-20120803 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpnBKXlD4gyJ.pgp
Description: PGP signature
Re: [PATCH 0/4] promote zcache from staging
Hi Konrad, On Tue, Jul 31, 2012 at 01:51:42PM -0400, Konrad Rzeszutek Wilk wrote: > On Tue, Jul 31, 2012 at 09:19:16AM -0700, Greg Kroah-Hartman wrote: > > On Tue, Jul 31, 2012 at 11:58:43AM -0400, Konrad Rzeszutek Wilk wrote: > > > So in my head I feel that it is Ok to: > > > 1) address the concerns that zcache has before it is unstaged > > > 2) rip out the two-engine system with a one-engine system > > >(and see how well it behaves) > > > 3) sysfs->debugfs as needed > > > 4) other things as needed > > > > > > I think we are getting hung-up what Greg said about adding features > > > and the two-engine->one engine could be understood as that. > > > While I think that is part of a staging effort to clean up the > > > existing issues. Lets see what Greg thinks. > > > > Greg has no idea, except I want to see the needed fixups happen before > > new features get added. Add the new features _after_ it is out of > > staging. > > I think we (that is me, Seth, Minchan, Dan) need to talk to have a good > understanding of what each of us thinks are fixups. > > Would Monday Aug 6th at 1pm EST on irc.freenode.net channel #zcache work > for people? 1pm EST is 2am KST(Korea Standard Time) so it's not good for me. :) I know it's hard to adjust my time for yours so let you talk without me. Instead, I will write it down my requirement. It's very simple and trivial. 1) Please don't add any new feature like replace zsmalloc with zbud. It's totally untested so it needs more time for stable POV bug, or performance/fragementation. 2) Factor out common code between zcache and ramster. It should be just clean up code and should not change current behavior. 3) Add lots of comment to public functions 4) make function/varabiel names more clearly. They are necessary for promotion and after promotion, let's talk about new great features. > > > > > greg k-h > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind regards, Minchan Kim -- 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/
PROBLEM: New Kernel Patch
Here is a new patch that should be tested that fixes a function issue in the description for the Mac80211 driver in tar.bz2 format. Let me know if it works. Thanks, -- Christopher patch-3.5.tar.bz2 Description: BZip2 compressed data
Re: WARNING: at mm/page_alloc.c:4514 free_area_init_node+0x4f/0x37b()
Hi Borislav,
On Thu, Aug 02, 2012 at 01:06:41PM +0200, Borislav Petkov wrote:
> On Thu, Aug 02, 2012 at 08:33:35AM +0900, Minchan Kim wrote:
> > Hello Borislav,
> >
> > On Wed, Aug 01, 2012 at 07:38:37PM +0200, Borislav Petkov wrote:
> > > Hi,
> > >
> > > I'm hitting the WARN_ON in $Subject with latest linus:
> > > v3.5-8833-g2d534926205d on a 4-node AMD system. As it looks from
> > > dmesg, it is happening on node 0, 1 and 2 but not on 3. Probably the
> > > pgdat->nr_zones thing but I'll have to add more dbg code to be sure.
> >
> > As I look the code quickly, free_area_init_node initializes node_id and
> > node_start_pfn doublely. They were initialized by setup_node_data.
> >
> > Could you test below patch? It's not a totally right way to fix it but
> > I want to confirm why it happens.
> >
> > (I'm on vacation now so please understand that it hard to reach me)
>
> I sincerely hope you're not going to interrupt your vacation because of
> this.
>
> :-).
>
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 889532b..009ac28 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -4511,7 +4511,7 @@ void __paginginit free_area_init_node(int nid,
> > unsigned long *zones_size,
> > pg_data_t *pgdat = NODE_DATA(nid);
> >
> > /* pg_data_t should be reset to zero when it's allocated */
> > - WARN_ON(pgdat->nr_zones || pgdat->node_start_pfn ||
> > pgdat->classzone_idx);
> > + WARN_ON(pgdat->nr_zones || pgdat->classzone_idx);
> >
> > pgdat->node_id = nid;
> > pgdat->node_start_pfn = node_start_pfn;
>
> Yep, you were right: ->node_start_pfn is set. I added additional debug
> output for more info:
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 889532b8e6c1..c249abe4fee2 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4511,7 +4511,17 @@ void __paginginit free_area_init_node(int nid,
> unsigned long *zones_size,
> pg_data_t *pgdat = NODE_DATA(nid);
>
> /* pg_data_t should be reset to zero when it's allocated */
> - WARN_ON(pgdat->nr_zones || pgdat->node_start_pfn ||
> pgdat->classzone_idx);
> + WARN_ON(pgdat->nr_zones || pgdat->classzone_idx);
> +
> + if (pgdat->node_start_pfn)
> + pr_warn("%s: pgdat->node_start_pfn: %lu\n", __func__,
> pgdat->node_start_pfn);
> +
> + if (pgdat->nr_zones)
> + pr_warn("%s: pgdat->nr_zones: %d\n", __func__,
> pgdat->nr_zones);
> +
> + if (pgdat->classzone_idx)
> + pr_warn("%s: pgdat->classzone_idx: %d\n", __func__,
> pgdat->classzone_idx);
> +
>
> pgdat->node_id = nid;
> pgdat->node_start_pfn = node_start_pfn;
>
>
>
> Here's what it says:
>
> [0.00] On node 0 totalpages: 4193848
> [0.00] DMA zone: 64 pages used for memmap
> [0.00] DMA zone: 6 pages reserved
> [0.00] DMA zone: 3890 pages, LIFO batch:0
> [0.00] DMA32 zone: 16320 pages used for memmap
> [0.00] DMA32 zone: 798464 pages, LIFO batch:31
> [0.00] Normal zone: 52736 pages used for memmap
> [0.00] Normal zone: 3322368 pages, LIFO batch:31
> [0.00] free_area_init_node: pgdat->node_start_pfn: 4423680<
> [0.00] On node 1 totalpages: 4194304
> [0.00] Normal zone: 65536 pages used for memmap
> [0.00] Normal zone: 4128768 pages, LIFO batch:31
> [0.00] free_area_init_node: pgdat->node_start_pfn: 8617984<
> [0.00] On node 2 totalpages: 4194304
> [0.00] Normal zone: 65536 pages used for memmap
> [0.00] Normal zone: 4128768 pages, LIFO batch:31
> [0.00] free_area_init_node: pgdat->node_start_pfn: 12812288 <
> [0.00] On node 3 totalpages: 4194304
> [0.00] Normal zone: 65536 pages used for memmap
> [0.00] Normal zone: 4128768 pages, LIFO batch:31
> [0.00] ACPI: PM-Timer IO Port: 0x2008
> [0.00] ACPI: Local APIC address 0xfee0
>
> Thanks.
Thanks for looking at this!
As soon as I come back from vacation, I see this BUG carefully and think patch
I sent
is good. The patch's goal is to detect for uninitialized pgdat structure
when it was allocated. So it checks some variables randomly but unfortunately,
pgdat's members like node_start_pfn are closely related to boot arch code
so some members could be used by arch code before reaching generic mm code.
It was a Tejun's concern and he was correct.
I think nr_zones and classzone_idx should be initialized by only generic MM code
during boot sequence, not memory hotplug so that patch would be okay.
Linus already applied the patch in rc-1 but he might need better changelog.
I am not sure I send this patch to whom, Linus or Andrew?
Anyway, Please use below if really need it.
Thanks!
>From b575b78a1ba7daf7a9adc3b49dadfbd573be398d Mon Sep 17 00:00:00 2001
From: Minchan Kim
Date: Mon, 6 Aug 2012 08:57:57 +0900
Subject: [PATCH] mm: fix wrong warning
[PATCH 15/15] PM: Do not use the syscore flag for runtime PM
The syscore device PM flag used to mark the devices (belonging to
PM domains) that should never be turned off, except for the system
core (syscore) suspend/hibernation and resume stages, need not be
accessed by the runtime PM core functions, because all of the devices
it is set for need to be marked as "irq safe" anyway and are
protected from being turned off by runtime PM by ensuring that their
usage counters are always set.
For this reason, make the syscore flag system-wide PM-specific
and simplify the code used for manipulating it, because it need not
acquire the device's power.lock any more.
Signed-off-by: Rafael J. Wysocki
---
drivers/base/power/common.c | 15 ---
drivers/base/power/domain.c |2 +-
drivers/base/power/runtime.c |2 +-
include/linux/device.h |7 +++
include/linux/pm.h |6 +-
5 files changed, 10 insertions(+), 22 deletions(-)
Index: linux/include/linux/pm.h
===
--- linux.orig/include/linux/pm.h
+++ linux/include/linux/pm.h
@@ -43,12 +43,8 @@ struct device;
#ifdef CONFIG_PM
extern const char power_group_name[]; /* = "power" */
-
-extern void dev_pm_syscore_device(struct device *dev, bool val);
#else
#define power_group_name NULL
-
-static inline void dev_pm_syscore_device(struct device *dev, bool val) {}
#endif
typedef struct pm_message {
@@ -515,13 +511,13 @@ struct dev_pm_info {
boolis_suspended:1; /* Ditto */
boolignore_children:1;
boolearly_init:1; /* Owned by the PM core */
- boolsyscore:1;
spinlock_t lock;
#ifdef CONFIG_PM_SLEEP
struct list_headentry;
struct completion completion;
struct wakeup_source*wakeup;
boolwakeup_path:1;
+ boolsyscore:1;
#else
unsigned intshould_wakeup:1;
#endif
Index: linux/drivers/base/power/common.c
===
--- linux.orig/drivers/base/power/common.c
+++ linux/drivers/base/power/common.c
@@ -85,18 +85,3 @@ int dev_pm_put_subsys_data(struct device
return ret;
}
EXPORT_SYMBOL_GPL(dev_pm_put_subsys_data);
-
-/**
- * dev_pm_syscore_device - Set/unset the given device's power.syscore flag.
- * @dev: Device whose flag is to be modified.
- * @val: New value of the flag.
- */
-void dev_pm_syscore_device(struct device *dev, bool val)
-{
- unsigned long flags;
-
- spin_lock_irqsave(>power.lock, flags);
- dev->power.syscore = val;
- spin_unlock_irqrestore(>power.lock, flags);
-}
-EXPORT_SYMBOL_GPL(dev_pm_syscore_device);
Index: linux/drivers/base/power/runtime.c
===
--- linux.orig/drivers/base/power/runtime.c
+++ linux/drivers/base/power/runtime.c
@@ -134,7 +134,7 @@ static int rpm_check_suspend_allowed(str
if (dev->power.runtime_error)
retval = -EINVAL;
- else if (dev->power.disable_depth > 0 || dev->power.syscore)
+ else if (dev->power.disable_depth > 0)
retval = -EACCES;
else if (atomic_read(>power.usage_count) > 0)
retval = -EAGAIN;
Index: linux/include/linux/device.h
===
--- linux.orig/include/linux/device.h
+++ linux/include/linux/device.h
@@ -772,6 +772,13 @@ static inline void pm_suspend_ignore_chi
dev->power.ignore_children = enable;
}
+static inline void dev_pm_syscore_device(struct device *dev, bool val)
+{
+#ifdef CONFIG_PM_SLEEP
+ dev->power.syscore = val;
+#endif
+}
+
static inline void device_lock(struct device *dev)
{
mutex_lock(>mutex);
Index: linux/drivers/base/power/domain.c
===
--- linux.orig/drivers/base/power/domain.c
+++ linux/drivers/base/power/domain.c
@@ -442,7 +442,7 @@ static int pm_genpd_poweroff(struct gene
not_suspended = 0;
list_for_each_entry(pdd, >dev_list, list_node)
if (pdd->dev->driver && (!pm_runtime_suspended(pdd->dev)
- || pdd->dev->power.irq_safe || pdd->dev->power.syscore))
+ || pdd->dev->power.irq_safe))
not_suspended++;
if (not_suspended > genpd->in_progress)
--
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/
[PATCH 2/15] PM / Domains: Add power off/on function for system core suspend stage
Introduce function pm_genpd_syscore_switch() and two wrappers around
it, pm_genpd_syscore_poweroff() and pm_genpd_syscore_poweron(),
allowing the callers to let the generic PM domains framework know
that the given device is not necessary any more and its PM domain
can be turned off (the former) or that the given device will be
required immediately, so its PM domain has to be turned on (the
latter) during the system core (syscore) stage of system suspend
(or hibernation) and resume.
These functions will be used for handling devices registered as
clock sources and clock event devices that belong to PM domains.
Signed-off-by: Rafael J. Wysocki
---
drivers/base/power/domain.c | 57 +++-
include/linux/pm_domain.h | 16
kernel/power/Kconfig|4 +++
3 files changed, 71 insertions(+), 6 deletions(-)
Index: linux/drivers/base/power/domain.c
===
--- linux.orig/drivers/base/power/domain.c
+++ linux/drivers/base/power/domain.c
@@ -697,6 +697,24 @@ static inline void genpd_power_off_work_
#ifdef CONFIG_PM_SLEEP
+/**
+ * pm_genpd_present - Check if the given PM domain has been initialized.
+ * @genpd: PM domain to check.
+ */
+static bool pm_genpd_present(struct generic_pm_domain *genpd)
+{
+ struct generic_pm_domain *gpd;
+
+ if (IS_ERR_OR_NULL(genpd))
+ return false;
+
+ list_for_each_entry(gpd, _list, gpd_list_node)
+ if (gpd == genpd)
+ return true;
+
+ return false;
+}
+
static bool genpd_dev_active_wakeup(struct generic_pm_domain *genpd,
struct device *dev)
{
@@ -750,9 +768,10 @@ static int genpd_thaw_dev(struct generic
* Check if the given PM domain can be powered off (during system suspend or
* hibernation) and do that if so. Also, in that case propagate to its
masters.
*
- * This function is only called in "noirq" stages of system power transitions,
- * so it need not acquire locks (all of the "noirq" callbacks are executed
- * sequentially, so it is guaranteed that it will never run twice in parallel).
+ * This function is only called in "noirq" and "syscore" stages of system power
+ * transitions, so it need not acquire locks (all of the "noirq" callbacks are
+ * executed sequentially, so it is guaranteed that it will never run twice in
+ * parallel).
*/
static void pm_genpd_sync_poweroff(struct generic_pm_domain *genpd)
{
@@ -780,9 +799,10 @@ static void pm_genpd_sync_poweroff(struc
* pm_genpd_sync_poweron - Synchronously power on a PM domain and its masters.
* @genpd: PM domain to power on.
*
- * This function is only called in "noirq" stage of system power transitions,
so
- * it need not acquire locks (all of the "noirq" callbacks are executed
- * sequentially, so it is guaranteed that it will never run twice in parallel).
+ * This function is only called in "noirq" and "syscore" stages of system power
+ * transitions, so it need not acquire locks (all of the "noirq" callbacks are
+ * executed sequentially, so it is guaranteed that it will never run twice in
+ * parallel).
*/
static void pm_genpd_sync_poweron(struct generic_pm_domain *genpd)
{
@@ -1272,6 +1292,31 @@ static void pm_genpd_complete(struct dev
}
}
+/**
+ * pm_genpd_syscore_switch - Switch power during system core suspend or resume.
+ * @dev: Device that normally is marked as "always on" to switch power for.
+ *
+ * This routine may only be called during the system core (syscore) suspend or
+ * resume phase for devices whose "always on" flags are set.
+ */
+void pm_genpd_syscore_switch(struct device *dev, bool suspend)
+{
+ struct generic_pm_domain *genpd;
+
+ genpd = dev_to_genpd(dev);
+ if (!pm_genpd_present(genpd))
+ return;
+
+ if (suspend) {
+ genpd->suspended_count++;
+ pm_genpd_sync_poweroff(genpd);
+ } else {
+ pm_genpd_sync_poweron(genpd);
+ genpd->suspended_count--;
+ }
+}
+EXPORT_SYMBOL_GPL(pm_genpd_syscore_switch);
+
#else
#define pm_genpd_prepare NULL
Index: linux/include/linux/pm_domain.h
===
--- linux.orig/include/linux/pm_domain.h
+++ linux/include/linux/pm_domain.h
@@ -258,4 +258,20 @@ static inline void genpd_queue_power_off
static inline void pm_genpd_poweroff_unused(void) {}
#endif
+#ifdef CONFIG_PM_GENERIC_DOMAINS_SLEEP
+extern void pm_genpd_syscore_switch(struct device *dev, bool suspend);
+#else
+static inline void pm_genpd_syscore_switch(struct device *dev, bool suspend) {}
+#endif
+
+static inline void pm_genpd_syscore_poweroff(struct device *dev)
+{
+ pm_genpd_syscore_switch(dev, true);
+}
+
+static inline void pm_genpd_syscore_poweron(struct device *dev)
+{
+ pm_genpd_syscore_switch(dev, false);
+}
+
#endif /* _LINUX_PM_DOMAIN_H
[PATCH 4/15] sh: TMU: Introduce clocksource/clock events suspend/resume routines
Introduce suspend/resume routines for SH TMU clock source and
clock event device such that if those devices belong to a PM domain,
the generic PM domains framework will be notified that the given
domain may be turned off (during system suspend) or that it has to
be turned on (during system resume).
This change allows the A4R domain on SH7372 to be turned off during
system suspend (tested on the Mackerel board) if the TMU clock source
and/or clock event device is in use.
Signed-off-by: Rafael J. Wysocki
---
drivers/clocksource/sh_tmu.c | 54 +++
1 file changed, 50 insertions(+), 4 deletions(-)
Index: linux/drivers/clocksource/sh_tmu.c
===
--- linux.orig/drivers/clocksource/sh_tmu.c
+++ linux/drivers/clocksource/sh_tmu.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
struct sh_tmu_priv {
void __iomem *mapbase;
@@ -43,6 +44,7 @@ struct sh_tmu_priv {
unsigned long periodic;
struct clock_event_device ced;
struct clocksource cs;
+ bool cs_enabled;
};
static DEFINE_RAW_SPINLOCK(sh_tmu_lock);
@@ -204,14 +206,40 @@ static int sh_tmu_clocksource_enable(str
int ret;
ret = sh_tmu_enable(p);
- if (!ret)
+ if (!ret) {
__clocksource_updatefreq_hz(cs, p->rate);
+ p->cs_enabled = true;
+ }
return ret;
}
static void sh_tmu_clocksource_disable(struct clocksource *cs)
{
- sh_tmu_disable(cs_to_sh_tmu(cs));
+ struct sh_tmu_priv *p = cs_to_sh_tmu(cs);
+
+ WARN_ON(!p->cs_enabled);
+
+ sh_tmu_disable(p);
+ p->cs_enabled = false;
+}
+
+static void sh_tmu_clocksource_suspend(struct clocksource *cs)
+{
+ struct sh_tmu_priv *p = cs_to_sh_tmu(cs);
+
+ if (p->cs_enabled)
+ sh_tmu_disable(p);
+
+ pm_genpd_syscore_poweroff(>pdev->dev);
+}
+
+static void sh_tmu_clocksource_resume(struct clocksource *cs)
+{
+ struct sh_tmu_priv *p = cs_to_sh_tmu(cs);
+
+ pm_genpd_syscore_poweron(>pdev->dev);
+ if (p->cs_enabled)
+ sh_tmu_enable(p);
}
static int sh_tmu_register_clocksource(struct sh_tmu_priv *p,
@@ -224,6 +252,8 @@ static int sh_tmu_register_clocksource(s
cs->read = sh_tmu_clocksource_read;
cs->enable = sh_tmu_clocksource_enable;
cs->disable = sh_tmu_clocksource_disable;
+ cs->suspend = sh_tmu_clocksource_suspend;
+ cs->resume = sh_tmu_clocksource_resume;
cs->mask = CLOCKSOURCE_MASK(32);
cs->flags = CLOCK_SOURCE_IS_CONTINUOUS;
@@ -301,6 +331,16 @@ static int sh_tmu_clock_event_next(unsig
return 0;
}
+static void sh_tmu_clock_event_suspend(struct clock_event_device *ced)
+{
+ pm_genpd_syscore_poweroff(_to_sh_tmu(ced)->pdev->dev);
+}
+
+static void sh_tmu_clock_event_resume(struct clock_event_device *ced)
+{
+ pm_genpd_syscore_poweron(_to_sh_tmu(ced)->pdev->dev);
+}
+
static void sh_tmu_register_clockevent(struct sh_tmu_priv *p,
char *name, unsigned long rating)
{
@@ -316,6 +356,8 @@ static void sh_tmu_register_clockevent(s
ced->cpumask = cpumask_of(0);
ced->set_next_event = sh_tmu_clock_event_next;
ced->set_mode = sh_tmu_clock_event_mode;
+ ced->suspend = sh_tmu_clock_event_suspend;
+ ced->resume = sh_tmu_clock_event_resume;
dev_info(>pdev->dev, "used for clock events\n");
@@ -407,8 +449,12 @@ static int __devinit sh_tmu_probe(struct
struct sh_tmu_priv *p = platform_get_drvdata(pdev);
int ret;
- if (!is_early_platform_device(pdev))
- pm_genpd_dev_always_on(>dev, true);
+ if (!is_early_platform_device(pdev)) {
+ struct sh_timer_config *cfg = pdev->dev.platform_data;
+
+ if (cfg->clocksource_rating || cfg->clockevent_rating)
+ pm_genpd_dev_always_on(>dev, true);
+ }
if (p) {
dev_info(>dev, "kept as earlytimer\n");
--
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/
[PATCH 0/15] PM: Suspend/resume and runtime PM for clock sources/clock event devices in PM domains
Hi all, On Sunday, July 29, 2012, Rafael J. Wysocki wrote: > There is a problem with clock sources and clock event devices belonging to PM > domains that they have to be marked as "always on", to prevent those domains > from being turned off unexpectedly, which also prevents the domains from > being turned off during system suspend, although that might be done and would > be desirable. > > The following patch series introduces a mechanism by which the generic PM > domains framework can be notified that a given domain may be turned off > after timekeeping has been suspended, which allows the domains that contain > clock sources and clock event devices to be turned off before the system > enters the target sleep state (so that less power is used in that state). > > [1/6] Introduce simplified power on routine for PM domains (to be used during > system resume from suspend/hibernation and during "syscore" resume). > [2/6] Introduce function for notifying the generic PM domains framework that > the given device may be treated as suspended (so its domain may be > turned off if this has been the last active device in it). > [3/6] Introduce suspend/resume callbacks for clock event devices. > [4/6] Make the SH TMU driver use suspend/resume callbacks for clock sources > and clock event devices to notify the generic PM domains framework that > those devices may be regarded as suspended (during system suspend) or > that they have to be turned on immediately (during system resume). > [5/6] Like [4/6] but for the SH CMT driver. > [6/6] Analogous to [4/6], but for the SH MTU2 driver. > > The patchset has been tested on the SH7372 Mackerel board. There were no comments, so I think I can go a bit further and add runtime PM support to those drivers too. :-) This requires some core changes, but they aren't too invasive in my opinion. Patches [1-6/15] are more-or-less the same as before modulo some fixes for bugs found during more thorough testing. The remaining patches make the following changes: [7/15] - Clean up device PM initialization. [8/15] - Allow early platform device drivers to use runtime PM helper functions. [9/15] - Rename the "always_on" device flag to "syscore". [10/15] - Move the "syscore" flag to the core (from PM domains framework). [11/15] - Rework the "starting" of devices flagged as "irq safe" in PM domains. [12/15] - Add runtime PM support to the SH TMU driver. [13/15] - Add runtime PM support to the SH CMT driver. [14/15] - Add runtime PM support to the SH MTU2 driver. [15/15] - Stop using the "syscore" device flag for runtime PM. Thanks, Rafael -- 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/
[PATCH 3/15] timekeeping: Add suspend and resume of clock event devices
Some clock event devices, for example such that belong to PM domains,
need to be handled in a spcial way during the timekeeping suspend
and resume (which takes place in the system core, or "syscore",
stages of system power transitions) in analogy with clock sources.
Introduce .suspend() and .resume() callbacks for clock event devices
that will be executed by timekeeping_suspend/_resume(), respectively,
next the the clock sources' .suspend() and .resume() callbacks.
Signed-off-by: Rafael J. Wysocki
---
include/linux/clockchips.h |5 +
kernel/time/clockevents.c | 24
kernel/time/timekeeping.c |2 ++
3 files changed, 31 insertions(+)
Index: linux/include/linux/clockchips.h
===
--- linux.orig/include/linux/clockchips.h
+++ linux/include/linux/clockchips.h
@@ -97,6 +97,8 @@ struct clock_event_device {
void(*broadcast)(const struct cpumask *mask);
void(*set_mode)(enum clock_event_mode mode,
struct clock_event_device *);
+ void(*suspend)(struct clock_event_device *);
+ void(*resume)(struct clock_event_device *);
unsigned long min_delta_ticks;
unsigned long max_delta_ticks;
@@ -156,6 +158,9 @@ clockevents_calc_mult_shift(struct clock
freq, minsec);
}
+extern void clockevents_suspend(void);
+extern void clockevents_resume(void);
+
#ifdef CONFIG_GENERIC_CLOCKEVENTS
extern void clockevents_notify(unsigned long reason, void *arg);
#else
Index: linux/kernel/time/clockevents.c
===
--- linux.orig/kernel/time/clockevents.c
+++ linux/kernel/time/clockevents.c
@@ -397,6 +397,30 @@ void clockevents_exchange_device(struct
local_irq_restore(flags);
}
+/**
+ * clockevents_suspend - suspend clock devices
+ */
+void clockevents_suspend(void)
+{
+ struct clock_event_device *dev;
+
+ list_for_each_entry_reverse(dev, _devices, list)
+ if (dev->suspend)
+ dev->suspend(dev);
+}
+
+/**
+ * clockevents_resume - resume clock devices
+ */
+void clockevents_resume(void)
+{
+ struct clock_event_device *dev;
+
+ list_for_each_entry(dev, _devices, list)
+ if (dev->resume)
+ dev->resume(dev);
+}
+
#ifdef CONFIG_GENERIC_CLOCKEVENTS
/**
* clockevents_notify - notification about relevant events
Index: linux/kernel/time/timekeeping.c
===
--- linux.orig/kernel/time/timekeeping.c
+++ linux/kernel/time/timekeeping.c
@@ -750,6 +750,7 @@ static void timekeeping_resume(void)
read_persistent_clock();
+ clockevents_resume();
clocksource_resume();
write_seqlock_irqsave(>lock, flags);
@@ -809,6 +810,7 @@ static int timekeeping_suspend(void)
clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, NULL);
clocksource_suspend();
+ clockevents_suspend();
return 0;
}
--
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/
[PATCH 8/15] PM / Runtime: Allow helpers to be called by early platform drivers
Runtime PM helper functions, like pm_runtime_get_sync(), cannot be
called by early platform device drivers, because the devices' power
management locks are not initialized at that time. This is quite
inconvenient, so modify early_platform_add_devices() to initialize
the devices power management locks as appropriate and make sure that
they won't be initialized more than once if an early platform
device is going to be used as a regular one later.
Signed-off-by: Rafael J. Wysocki
---
drivers/base/platform.c|2 ++
drivers/base/power/power.h | 18 --
include/linux/pm.h |1 +
3 files changed, 19 insertions(+), 2 deletions(-)
Index: linux/drivers/base/power/power.h
===
--- linux.orig/drivers/base/power/power.h
+++ linux/drivers/base/power/power.h
@@ -2,17 +2,31 @@
static inline void device_pm_init_common(struct device *dev)
{
- spin_lock_init(>power.lock);
- dev->power.power_state = PMSG_INVALID;
+ if (!dev->power.early_init) {
+ spin_lock_init(>power.lock);
+ dev->power.power_state = PMSG_INVALID;
+ dev->power.early_init = true;
+ }
}
#ifdef CONFIG_PM_RUNTIME
+static inline void pm_runtime_early_init(struct device *dev)
+{
+ dev->power.disable_depth = 1;
+ device_pm_init_common(dev);
+}
+
extern void pm_runtime_init(struct device *dev);
extern void pm_runtime_remove(struct device *dev);
#else /* !CONFIG_PM_RUNTIME */
+static inline void pm_runtime_early_init(struct device *dev)
+{
+ device_pm_init_common(dev);
+}
+
static inline void pm_runtime_init(struct device *dev) {}
static inline void pm_runtime_remove(struct device *dev) {}
Index: linux/include/linux/pm.h
===
--- linux.orig/include/linux/pm.h
+++ linux/include/linux/pm.h
@@ -510,6 +510,7 @@ struct dev_pm_info {
boolis_prepared:1; /* Owned by the PM core */
boolis_suspended:1; /* Ditto */
boolignore_children:1;
+ boolearly_init:1; /* Owned by the PM core */
spinlock_t lock;
#ifdef CONFIG_PM_SLEEP
struct list_headentry;
Index: linux/drivers/base/platform.c
===
--- linux.orig/drivers/base/platform.c
+++ linux/drivers/base/platform.c
@@ -22,6 +22,7 @@
#include
#include "base.h"
+#include "power/power.h"
#define to_platform_driver(drv)(container_of((drv), struct
platform_driver, \
driver))
@@ -948,6 +949,7 @@ void __init early_platform_add_devices(s
dev = [i]->dev;
if (!dev->devres_head.next) {
+ pm_runtime_early_init(dev);
INIT_LIST_HEAD(>devres_head);
list_add_tail(>devres_head,
_platform_device_list);
--
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/
[PATCH 10/15] PM / Domains: Move syscore flag from subsys data to struct device
The syscore device PM flag is used to mark the devices (belonging to
a PM domain) that should never be turned off, except for the system
core (syscore) suspend/hibernation and resume stages. That flag is
stored in the device's struct pm_subsys_data object whose address is
available from struct device. However, in some situations it may be
convenient to set that flag before the device is added to a PM
domain, so it is better to move it directly to the "power" member of
struct device. Then, it can be checked by the routines in
drivers/base/power/runtime.c and drivers/base/power/main.c, which is
more straightforward.
This also reduces the number of dev_gpd_data() invocations in the
generic PM domains framework, so the overhead related to the syscore
flag is slightly smaller.
Signed-off-by: Rafael J. Wysocki
---
drivers/base/power/common.c | 15 +++
drivers/base/power/domain.c | 37 ++---
drivers/base/power/main.c | 28
drivers/base/power/runtime.c |2 +-
drivers/clocksource/sh_cmt.c |2 +-
drivers/clocksource/sh_mtu2.c |2 +-
drivers/clocksource/sh_tmu.c |2 +-
include/linux/pm.h|5 +
include/linux/pm_domain.h |3 ---
9 files changed, 58 insertions(+), 38 deletions(-)
Index: linux/drivers/base/power/common.c
===
--- linux.orig/drivers/base/power/common.c
+++ linux/drivers/base/power/common.c
@@ -85,3 +85,18 @@ int dev_pm_put_subsys_data(struct device
return ret;
}
EXPORT_SYMBOL_GPL(dev_pm_put_subsys_data);
+
+/**
+ * dev_pm_syscore_device - Set/unset the given device's power.syscore flag.
+ * @dev: Device whose flag is to be modified.
+ * @val: New value of the flag.
+ */
+void dev_pm_syscore_device(struct device *dev, bool val)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(>power.lock, flags);
+ dev->power.syscore = val;
+ spin_unlock_irqrestore(>power.lock, flags);
+}
+EXPORT_SYMBOL_GPL(dev_pm_syscore_device);
Index: linux/drivers/clocksource/sh_cmt.c
===
--- linux.orig/drivers/clocksource/sh_cmt.c
+++ linux/drivers/clocksource/sh_cmt.c
@@ -717,7 +717,7 @@ static int __devinit sh_cmt_probe(struct
struct sh_timer_config *cfg = pdev->dev.platform_data;
if (cfg->clocksource_rating || cfg->clockevent_rating)
- pm_genpd_dev_syscore(>dev, true);
+ dev_pm_syscore_device(>dev, true);
}
if (p) {
Index: linux/drivers/clocksource/sh_mtu2.c
===
--- linux.orig/drivers/clocksource/sh_mtu2.c
+++ linux/drivers/clocksource/sh_mtu2.c
@@ -323,7 +323,7 @@ static int __devinit sh_mtu2_probe(struc
struct sh_timer_config *cfg = pdev->dev.platform_data;
if (cfg->clockevent_rating)
- pm_genpd_dev_syscore(>dev, true);
+ dev_pm_syscore_device(>dev, true);
}
if (p) {
Index: linux/drivers/clocksource/sh_tmu.c
===
--- linux.orig/drivers/clocksource/sh_tmu.c
+++ linux/drivers/clocksource/sh_tmu.c
@@ -453,7 +453,7 @@ static int __devinit sh_tmu_probe(struct
struct sh_timer_config *cfg = pdev->dev.platform_data;
if (cfg->clocksource_rating || cfg->clockevent_rating)
- pm_genpd_dev_syscore(>dev, true);
+ dev_pm_syscore_device(>dev, true);
}
if (p) {
Index: linux/include/linux/pm.h
===
--- linux.orig/include/linux/pm.h
+++ linux/include/linux/pm.h
@@ -43,8 +43,12 @@ struct device;
#ifdef CONFIG_PM
extern const char power_group_name[]; /* = "power" */
+
+extern void dev_pm_syscore_device(struct device *dev, bool val);
#else
#define power_group_name NULL
+
+static inline void dev_pm_syscore_device(struct device *dev, bool val) {}
#endif
typedef struct pm_message {
@@ -511,6 +515,7 @@ struct dev_pm_info {
boolis_suspended:1; /* Ditto */
boolignore_children:1;
boolearly_init:1; /* Owned by the PM core */
+ boolsyscore:1;
spinlock_t lock;
#ifdef CONFIG_PM_SLEEP
struct list_headentry;
Index: linux/drivers/base/power/runtime.c
===
--- linux.orig/drivers/base/power/runtime.c
+++ linux/drivers/base/power/runtime.c
@@ -134,7 +134,7 @@ static int rpm_check_suspend_allowed(str
if (dev->power.runtime_error)
retval = -EINVAL;
- else if (dev->power.disable_depth > 0)
+ else if (dev->power.disable_depth > 0 ||
[PATCH 7/15] PM: Reorganize device PM initialization
Make the device power management initialization more straightforward
by moving the initialization of common (i.e. used by both runtime PM
and system suspend) fields to a separate routine.
Signed-off-by: Rafael J. Wysocki
---
drivers/base/power/main.c |7 ++-
drivers/base/power/power.h | 22 +++---
2 files changed, 17 insertions(+), 12 deletions(-)
Index: linux/drivers/base/power/main.c
===
--- linux.orig/drivers/base/power/main.c
+++ linux/drivers/base/power/main.c
@@ -57,20 +57,17 @@ static pm_message_t pm_transition;
static int async_error;
/**
- * device_pm_init - Initialize the PM-related part of a device object.
+ * device_pm_sleep_init - Initialize system suspend-related device fields.
* @dev: Device object being initialized.
*/
-void device_pm_init(struct device *dev)
+void device_pm_sleep_init(struct device *dev)
{
dev->power.is_prepared = false;
dev->power.is_suspended = false;
init_completion(>power.completion);
complete_all(>power.completion);
dev->power.wakeup = NULL;
- spin_lock_init(>power.lock);
- pm_runtime_init(dev);
INIT_LIST_HEAD(>power.entry);
- dev->power.power_state = PMSG_INVALID;
}
/**
Index: linux/drivers/base/power/power.h
===
--- linux.orig/drivers/base/power/power.h
+++ linux/drivers/base/power/power.h
@@ -1,5 +1,11 @@
#include
+static inline void device_pm_init_common(struct device *dev)
+{
+ spin_lock_init(>power.lock);
+ dev->power.power_state = PMSG_INVALID;
+}
+
#ifdef CONFIG_PM_RUNTIME
extern void pm_runtime_init(struct device *dev);
@@ -25,7 +31,7 @@ static inline struct device *to_device(s
return container_of(entry, struct device, power.entry);
}
-extern void device_pm_init(struct device *dev);
+extern void device_pm_sleep_init(struct device *dev);
extern void device_pm_add(struct device *);
extern void device_pm_remove(struct device *);
extern void device_pm_move_before(struct device *, struct device *);
@@ -34,12 +40,7 @@ extern void device_pm_move_last(struct d
#else /* !CONFIG_PM_SLEEP */
-static inline void device_pm_init(struct device *dev)
-{
- spin_lock_init(>power.lock);
- dev->power.power_state = PMSG_INVALID;
- pm_runtime_init(dev);
-}
+static inline void device_pm_sleep_init(struct device *dev) {}
static inline void device_pm_add(struct device *dev)
{
@@ -60,6 +61,13 @@ static inline void device_pm_move_last(s
#endif /* !CONFIG_PM_SLEEP */
+static inline void device_pm_init(struct device *dev)
+{
+ device_pm_init_common(dev);
+ device_pm_sleep_init(dev);
+ pm_runtime_init(dev);
+}
+
#ifdef CONFIG_PM
/*
--
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/
[PATCH 12/15] sh: TMU: Basic runtime PM support
Modify the SH TMU clock source/clock event device driver to support
runtime PM at a basic level (i.e. device clocks can be disabled and
enabled, but domain power must be on, because the devices have to
be marked as "irq safe").
Signed-off-by: Rafael J. Wysocki
---
drivers/clocksource/sh_tmu.c | 80 ++-
1 file changed, 65 insertions(+), 15 deletions(-)
Index: linux/drivers/clocksource/sh_tmu.c
===
--- linux.orig/drivers/clocksource/sh_tmu.c
+++ linux/drivers/clocksource/sh_tmu.c
@@ -45,6 +45,7 @@ struct sh_tmu_priv {
struct clock_event_device ced;
struct clocksource cs;
bool cs_enabled;
+ unsigned int enable_count;
};
static DEFINE_RAW_SPINLOCK(sh_tmu_lock);
@@ -109,7 +110,7 @@ static void sh_tmu_start_stop_ch(struct
raw_spin_unlock_irqrestore(_tmu_lock, flags);
}
-static int sh_tmu_enable(struct sh_tmu_priv *p)
+static int __sh_tmu_enable(struct sh_tmu_priv *p)
{
int ret;
@@ -137,7 +138,18 @@ static int sh_tmu_enable(struct sh_tmu_p
return 0;
}
-static void sh_tmu_disable(struct sh_tmu_priv *p)
+static int sh_tmu_enable(struct sh_tmu_priv *p)
+{
+ if (p->enable_count++ > 0)
+ return 0;
+
+ pm_runtime_get_sync(>pdev->dev);
+ dev_pm_syscore_device(>pdev->dev, true);
+
+ return __sh_tmu_enable(p);
+}
+
+static void __sh_tmu_disable(struct sh_tmu_priv *p)
{
/* disable channel */
sh_tmu_start_stop_ch(p, 0);
@@ -149,6 +161,20 @@ static void sh_tmu_disable(struct sh_tmu
clk_disable(p->clk);
}
+static void sh_tmu_disable(struct sh_tmu_priv *p)
+{
+ if (WARN_ON(p->enable_count == 0))
+ return;
+
+ if (--p->enable_count > 0)
+ return;
+
+ __sh_tmu_disable(p);
+
+ dev_pm_syscore_device(>pdev->dev, false);
+ pm_runtime_put(>pdev->dev);
+}
+
static void sh_tmu_set_next(struct sh_tmu_priv *p, unsigned long delta,
int periodic)
{
@@ -205,11 +231,15 @@ static int sh_tmu_clocksource_enable(str
struct sh_tmu_priv *p = cs_to_sh_tmu(cs);
int ret;
+ if (WARN_ON(p->cs_enabled))
+ return 0;
+
ret = sh_tmu_enable(p);
if (!ret) {
__clocksource_updatefreq_hz(cs, p->rate);
p->cs_enabled = true;
}
+
return ret;
}
@@ -217,7 +247,8 @@ static void sh_tmu_clocksource_disable(s
{
struct sh_tmu_priv *p = cs_to_sh_tmu(cs);
- WARN_ON(!p->cs_enabled);
+ if (WARN_ON(!p->cs_enabled))
+ return;
sh_tmu_disable(p);
p->cs_enabled = false;
@@ -227,19 +258,26 @@ static void sh_tmu_clocksource_suspend(s
{
struct sh_tmu_priv *p = cs_to_sh_tmu(cs);
- if (p->cs_enabled)
- sh_tmu_disable(p);
+ if (!p->cs_enabled)
+ return;
- pm_genpd_syscore_poweroff(>pdev->dev);
+ if (--p->enable_count == 0) {
+ __sh_tmu_disable(p);
+ pm_genpd_syscore_poweroff(>pdev->dev);
+ }
}
static void sh_tmu_clocksource_resume(struct clocksource *cs)
{
struct sh_tmu_priv *p = cs_to_sh_tmu(cs);
- pm_genpd_syscore_poweron(>pdev->dev);
- if (p->cs_enabled)
- sh_tmu_enable(p);
+ if (!p->cs_enabled)
+ return;
+
+ if (p->enable_count++ == 0) {
+ pm_genpd_syscore_poweron(>pdev->dev);
+ __sh_tmu_enable(p);
+ }
}
static int sh_tmu_register_clocksource(struct sh_tmu_priv *p,
@@ -434,6 +472,8 @@ static int sh_tmu_setup(struct sh_tmu_pr
ret = PTR_ERR(p->clk);
goto err1;
}
+ p->cs_enabled = false;
+ p->enable_count = 0;
return sh_tmu_register(p, (char *)dev_name(>pdev->dev),
cfg->clockevent_rating,
@@ -447,18 +487,17 @@ static int sh_tmu_setup(struct sh_tmu_pr
static int __devinit sh_tmu_probe(struct platform_device *pdev)
{
struct sh_tmu_priv *p = platform_get_drvdata(pdev);
+ struct sh_timer_config *cfg = pdev->dev.platform_data;
int ret;
if (!is_early_platform_device(pdev)) {
- struct sh_timer_config *cfg = pdev->dev.platform_data;
-
- if (cfg->clocksource_rating || cfg->clockevent_rating)
- dev_pm_syscore_device(>dev, true);
+ pm_runtime_set_active(>dev);
+ pm_runtime_enable(>dev);
}
if (p) {
dev_info(>dev, "kept as earlytimer\n");
- return 0;
+ goto out;
}
p = kmalloc(sizeof(*p), GFP_KERNEL);
@@ -471,8 +510,19 @@ static int __devinit sh_tmu_probe(struct
if (ret) {
kfree(p);
platform_set_drvdata(pdev, NULL);
+ pm_runtime_idle(>dev);
+ return ret;
}
-
[PATCH 5/15] sh: CMT: Introduce clocksource/clock events suspend/resume routines
Introduce suspend/resume routines for SH CMT clock event devices and
modify the suspend/resume routines for SH CMT clock sources such that
if those devices belong to a PM domain, the generic PM domains
framework will be notified that the given domain may be turned off
(during system suspend) or that it has to be turned on (during system
resume).
Signed-off-by: Rafael J. Wysocki
---
drivers/clocksource/sh_cmt.c | 35 +++
1 file changed, 31 insertions(+), 4 deletions(-)
Index: linux/drivers/clocksource/sh_cmt.c
===
--- linux.orig/drivers/clocksource/sh_cmt.c
+++ linux/drivers/clocksource/sh_cmt.c
@@ -464,9 +464,20 @@ static void sh_cmt_clocksource_disable(s
sh_cmt_stop(cs_to_sh_cmt(cs), FLAG_CLOCKSOURCE);
}
+static void sh_cmt_clocksource_suspend(struct clocksource *cs)
+{
+ struct sh_cmt_priv *p = cs_to_sh_cmt(cs);
+
+ sh_cmt_stop(p, FLAG_CLOCKSOURCE);
+ pm_genpd_syscore_poweroff(>pdev->dev);
+}
+
static void sh_cmt_clocksource_resume(struct clocksource *cs)
{
- sh_cmt_start(cs_to_sh_cmt(cs), FLAG_CLOCKSOURCE);
+ struct sh_cmt_priv *p = cs_to_sh_cmt(cs);
+
+ pm_genpd_syscore_poweron(>pdev->dev);
+ sh_cmt_start(p, FLAG_CLOCKSOURCE);
}
static int sh_cmt_register_clocksource(struct sh_cmt_priv *p,
@@ -479,7 +490,7 @@ static int sh_cmt_register_clocksource(s
cs->read = sh_cmt_clocksource_read;
cs->enable = sh_cmt_clocksource_enable;
cs->disable = sh_cmt_clocksource_disable;
- cs->suspend = sh_cmt_clocksource_disable;
+ cs->suspend = sh_cmt_clocksource_suspend;
cs->resume = sh_cmt_clocksource_resume;
cs->mask = CLOCKSOURCE_MASK(sizeof(unsigned long) * 8);
cs->flags = CLOCK_SOURCE_IS_CONTINUOUS;
@@ -562,6 +573,16 @@ static int sh_cmt_clock_event_next(unsig
return 0;
}
+static void sh_cmt_clock_event_suspend(struct clock_event_device *ced)
+{
+ pm_genpd_syscore_poweroff(_to_sh_cmt(ced)->pdev->dev);
+}
+
+static void sh_cmt_clock_event_resume(struct clock_event_device *ced)
+{
+ pm_genpd_syscore_poweron(_to_sh_cmt(ced)->pdev->dev);
+}
+
static void sh_cmt_register_clockevent(struct sh_cmt_priv *p,
char *name, unsigned long rating)
{
@@ -576,6 +597,8 @@ static void sh_cmt_register_clockevent(s
ced->cpumask = cpumask_of(0);
ced->set_next_event = sh_cmt_clock_event_next;
ced->set_mode = sh_cmt_clock_event_mode;
+ ced->suspend = sh_cmt_clock_event_suspend;
+ ced->resume = sh_cmt_clock_event_resume;
dev_info(>pdev->dev, "used for clock events\n");
clockevents_register_device(ced);
@@ -690,8 +713,12 @@ static int __devinit sh_cmt_probe(struct
struct sh_cmt_priv *p = platform_get_drvdata(pdev);
int ret;
- if (!is_early_platform_device(pdev))
- pm_genpd_dev_always_on(>dev, true);
+ if (!is_early_platform_device(pdev)) {
+ struct sh_timer_config *cfg = pdev->dev.platform_data;
+
+ if (cfg->clocksource_rating || cfg->clockevent_rating)
+ pm_genpd_dev_always_on(>dev, true);
+ }
if (p) {
dev_info(>dev, "kept as earlytimer\n");
--
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/
[PATCH 6/15] sh: MTU2: Introduce clock events suspend/resume routines
Introduce suspend/resume routines for SH MTU2 clock event devices
such that if those devices belong to a PM domain, the generic PM
domains framework will be notified that the given domain may be
turned off (during system suspend) or that it has to be turned on
(during system resume).
Signed-off-by: Rafael J. Wysocki
---
drivers/clocksource/sh_mtu2.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
Index: linux/drivers/clocksource/sh_mtu2.c
===
--- linux.orig/drivers/clocksource/sh_mtu2.c
+++ linux/drivers/clocksource/sh_mtu2.c
@@ -208,6 +208,16 @@ static void sh_mtu2_clock_event_mode(enu
}
}
+static void sh_mtu2_clock_event_suspend(struct clock_event_device *ced)
+{
+ pm_genpd_syscore_poweroff(_to_sh_mtu2(ced)->pdev->dev);
+}
+
+static void sh_mtu2_clock_event_resume(struct clock_event_device *ced)
+{
+ pm_genpd_syscore_poweron(_to_sh_mtu2(ced)->pdev->dev);
+}
+
static void sh_mtu2_register_clockevent(struct sh_mtu2_priv *p,
char *name, unsigned long rating)
{
@@ -221,6 +231,8 @@ static void sh_mtu2_register_clockevent(
ced->rating = rating;
ced->cpumask = cpumask_of(0);
ced->set_mode = sh_mtu2_clock_event_mode;
+ ced->suspend = sh_mtu2_clock_event_suspend;
+ ced->resume = sh_mtu2_clock_event_resume;
dev_info(>pdev->dev, "used for clock events\n");
clockevents_register_device(ced);
@@ -307,8 +319,12 @@ static int __devinit sh_mtu2_probe(struc
struct sh_mtu2_priv *p = platform_get_drvdata(pdev);
int ret;
- if (!is_early_platform_device(pdev))
- pm_genpd_dev_always_on(>dev, true);
+ if (!is_early_platform_device(pdev)) {
+ struct sh_timer_config *cfg = pdev->dev.platform_data;
+
+ if (cfg->clockevent_rating)
+ pm_genpd_dev_always_on(>dev, true);
+ }
if (p) {
dev_info(>dev, "kept as earlytimer\n");
--
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/
[PATCH 13/15] sh: CMT: Basic runtime PM support
Modify the SH CMT clock source/clock event device driver to support
runtime PM at a basic level (i.e. device clocks can be disabled and
enabled, but domain power must be on, because the devices have to
be marked as "irq safe").
Signed-off-by: Rafael J. Wysocki
---
drivers/clocksource/sh_cmt.c | 44 +++
1 file changed, 36 insertions(+), 8 deletions(-)
Index: linux/drivers/clocksource/sh_cmt.c
===
--- linux.orig/drivers/clocksource/sh_cmt.c
+++ linux/drivers/clocksource/sh_cmt.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
struct sh_cmt_priv {
void __iomem *mapbase;
@@ -52,6 +53,7 @@ struct sh_cmt_priv {
struct clock_event_device ced;
struct clocksource cs;
unsigned long total_cycles;
+ bool cs_enabled;
};
static DEFINE_RAW_SPINLOCK(sh_cmt_lock);
@@ -155,6 +157,9 @@ static int sh_cmt_enable(struct sh_cmt_p
{
int k, ret;
+ pm_runtime_get_sync(>pdev->dev);
+ dev_pm_syscore_device(>pdev->dev, true);
+
/* enable clock */
ret = clk_enable(p->clk);
if (ret) {
@@ -221,6 +226,9 @@ static void sh_cmt_disable(struct sh_cmt
/* stop clock */
clk_disable(p->clk);
+
+ dev_pm_syscore_device(>pdev->dev, false);
+ pm_runtime_put(>pdev->dev);
}
/* private flags */
@@ -451,17 +459,26 @@ static int sh_cmt_clocksource_enable(str
int ret;
struct sh_cmt_priv *p = cs_to_sh_cmt(cs);
+ WARN_ON(p->cs_enabled);
+
p->total_cycles = 0;
ret = sh_cmt_start(p, FLAG_CLOCKSOURCE);
- if (!ret)
+ if (!ret) {
__clocksource_updatefreq_hz(cs, p->rate);
+ p->cs_enabled = true;
+ }
return ret;
}
static void sh_cmt_clocksource_disable(struct clocksource *cs)
{
- sh_cmt_stop(cs_to_sh_cmt(cs), FLAG_CLOCKSOURCE);
+ struct sh_cmt_priv *p = cs_to_sh_cmt(cs);
+
+ WARN_ON(!p->cs_enabled);
+
+ sh_cmt_stop(p, FLAG_CLOCKSOURCE);
+ p->cs_enabled = false;
}
static void sh_cmt_clocksource_suspend(struct clocksource *cs)
@@ -693,6 +710,7 @@ static int sh_cmt_setup(struct sh_cmt_pr
dev_err(>pdev->dev, "registration failed\n");
goto err1;
}
+ p->cs_enabled = false;
ret = setup_irq(irq, >irqaction);
if (ret) {
@@ -711,18 +729,17 @@ err0:
static int __devinit sh_cmt_probe(struct platform_device *pdev)
{
struct sh_cmt_priv *p = platform_get_drvdata(pdev);
+ struct sh_timer_config *cfg = pdev->dev.platform_data;
int ret;
if (!is_early_platform_device(pdev)) {
- struct sh_timer_config *cfg = pdev->dev.platform_data;
-
- if (cfg->clocksource_rating || cfg->clockevent_rating)
- dev_pm_syscore_device(>dev, true);
+ pm_runtime_set_active(>dev);
+ pm_runtime_enable(>dev);
}
if (p) {
dev_info(>dev, "kept as earlytimer\n");
- return 0;
+ goto out;
}
p = kmalloc(sizeof(*p), GFP_KERNEL);
@@ -735,8 +752,19 @@ static int __devinit sh_cmt_probe(struct
if (ret) {
kfree(p);
platform_set_drvdata(pdev, NULL);
+ pm_runtime_idle(>dev);
+ return ret;
}
- return ret;
+ if (is_early_platform_device(pdev))
+ return 0;
+
+ out:
+ if (cfg->clockevent_rating || cfg->clocksource_rating)
+ pm_runtime_irq_safe(>dev);
+ else
+ pm_runtime_idle(>dev);
+
+ return 0;
}
static int __devexit sh_cmt_remove(struct platform_device *pdev)
--
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/
