Re: [PATCH 1/7] I2c-nomadik: Fix the usage of wait_for_completion_timeout
> Thanks your pointing out. I just manually reviewed the code when found > this point. Would like to try some auto-script but failed:) I can suggest 'coccinelle' for that kind of job. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 1/2] drm: Add NVIDIA Tegra20 support
On 09.11.2012 15:59, Thierry Reding wrote: > This commit adds a KMS driver for the Tegra20 SoC. This includes basic > support for host1x and the two display controllers found on the Tegra20 > SoC. Each display controller can drive a separate RGB/LVDS output. Thanks Thierry for the hard work. I noticed the same thing Stephen noticed earlier - I couldn't compile the driver. Other than that, there were a couple of differences to the tree we've worked with and tested earlier: Tegra30 support was dropped and as a consequence so was IOMMU support. I'm perfectly fine with leaving out IOMMU support, because we had some problems with that and dma-buf. We were getting a bit worried about how to implement mapping and re-mapping dma-buf's without causing duplicate IOMMU mappings. Best regards, Terje -- 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 2/2] ARM: tegra: Add Tegra30 host1x support
On Tue, Nov 13, 2012 at 03:45:52PM +0800, Mark Zhang wrote:
> On 11/09/2012 09:20 PM, Thierry Reding wrote:
[...]
> > @@ -1337,6 +1337,9 @@ struct clk_duplicate tegra_clk_duplicates[] = {
> > CLK_DUPLICATE("pll_p_out3", "tegra-i2c.2", "fast-clk"),
> > CLK_DUPLICATE("pll_p_out3", "tegra-i2c.3", "fast-clk"),
> > CLK_DUPLICATE("pll_p_out3", "tegra-i2c.4", "fast-clk"),
> > + CLK_DUPLICATE("pll_p", "tegra-dc.0", "parent"),
> > + CLK_DUPLICATE("pll_p", "tegra-dc.1", "parent"),
> > + CLK_DUPLICATE("pll_d2_out0", "tegra-hdmi", "parent"),
> > };
>
> The tegra-dc.1's parent should be pll_d2_out0.
I've explained this my reply to the Tegra20 support patch.
Thierry
pgpsd2oRD0z0H.pgp
Description: PGP signature
Re: Fix lapic time counter read for periodic mode
Hi,
thanks for your reply.
On Mon, Nov 12, 2012 at 07:32:37PM -0200, Marcelo Tosatti wrote:
> > there is a bug in the emulation of the lapic time counter. In particular
> > what we are seeing is that the time counter of a periodic lapic timer
> > in the guest reads as zero 99% of the time. The patch below fixes that.
> >
> > The emulation of the lapic timer is done with the help of a hires
> > timer that expires with the same frequency as the lapic counter.
> > New expiration times for a periodic timer are calculated incrementally
> > based on the last scheduled expiration time. This ensures long term
> > accuracy of the emulated timer close to that of the underlying clock.
> >
> > The actual value of the lapic time counter is calculated from the
> > real time difference between current time and scheduled expiration time
> > of the hires timer. If this difference is negative, the hires timer
> > expired. For oneshot mode this is correctly translated into a zero value
> > for the time counter. However, in periodic mode we must use the negative
> > difference unmodified.
> >
> > regards Christian
> >
> > Fix lapic time counter read for periodic mode.
>
> In periodic mode the hrtimer is rearmed once expired, see
> apic_timer_fn. So _get_remaining should return proper value
> even if the guest is not able to process timer interrupts.
>
> Can you describe your specific scenario in more detail?
In my specific case, the host is admittedly somewhat special as it
already is a rehosted version of linux, i.e. not running directly on
native hardware. It is still unclear if the host has sufficiently accurate
timer interrupts. This is most likely part of the problems we are seeing.
However, AFAICS apic_timer_fn is only called once per jiffy (at least in
some configurations). In particular, it is not called by
hrtimer_get_remaining. Thus depending on the frequency of the LAPIC timer
in the guest there might _several_ iterations that are missed. This can
probably be mitigated by a hires timer interrupts. However, I think
the problem is still there even in that case.
Additionally, the behaviour that I want to establish matches that of the
PIT timer (in a not completely obvious way, though).
Having said that the proposed patch in my first mail is incomplete, as
the mod_64 does not work correctly for negative values. A fixed version
is below.
regards Christian
Signed-off-by: Christian Ehrhardt
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 43e9fad..ec7242c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -810,11 +810,22 @@ static u32 apic_get_tmcct(struct kvm_lapic *apic)
if (kvm_apic_get_reg(apic, APIC_TMICT) == 0)
return 0;
+ /*
+* hrtimer_get_remaining returns the signed difference between
+* timer expiration time and current time. Keep negative return
+* values iff the the timer is periodic.
+*/
remaining = hrtimer_get_remaining(>lapic_timer.timer);
- if (ktime_to_ns(remaining) < 0)
- remaining = ktime_set(0, 0);
+ ns = ktime_to_ns(remaining);
+ if (unlikely(ns < 0)) {
+ if (apic_lvtt_period(apic))
+ ns = apic->lapic_timer.period -
+ mod_64(-ns, apic->lapic_timer.period);
+ else
+ ns = 0;
+ }
- ns = mod_64(ktime_to_ns(remaining), apic->lapic_timer.period);
+ ns = mod_64(ns, apic->lapic_timer.period);
tmcct = div64_u64(ns,
(APIC_BUS_CYCLE_NS * apic->divide_count));
--
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] ALSA: es1968: precedence bug in snd_es1968_tea575x_get_pins()
At Tue, 13 Nov 2012 10:44:54 +0300, Dan Carpenter wrote: > > I don't think this works as intended. '|' higher precedence than ?: so > the bitwize OR "0 | (val & STR_MOST)" is a no-op. > > I have re-written it to be more clear. > > Signed-off-by: Dan Carpenter Thanks, applied now. Takashi > --- > I don't have a way to test this. > > diff --git a/sound/pci/es1968.c b/sound/pci/es1968.c > index 50169bc..7266020 100644 > --- a/sound/pci/es1968.c > +++ b/sound/pci/es1968.c > @@ -2581,9 +2581,14 @@ static u8 snd_es1968_tea575x_get_pins(struct > snd_tea575x *tea) > struct es1968 *chip = tea->private_data; > unsigned long io = chip->io_port + GPIO_DATA; > u16 val = inw(io); > - > - return (val & STR_DATA) ? TEA575X_DATA : 0 | > - (val & STR_MOST) ? TEA575X_MOST : 0; > + u8 ret; > + > + ret = 0; > + if (val & STR_DATA) > + ret |= TEA575X_DATA; > + if (val & STR_MOST) > + ret |= TEA575X_MOST; > + return ret; > } > > static void snd_es1968_tea575x_set_direction(struct snd_tea575x *tea, bool > output) > -- 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] ARM: tegra: Add Tegra20 host1x support
On Tue, Nov 13, 2012 at 03:45:00PM +0800, Mark Zhang wrote:
> On 11/09/2012 09:20 PM, Thierry Reding wrote:
> > @@ -116,6 +122,9 @@ static __initdata struct tegra_clk_init_table
> > tegra_dt_clk_init_table[] = {
> > { "sbc2", "pll_p",1, false },
> > { "sbc3", "pll_p",1, false },
> > { "sbc4", "pll_p",1, false },
> > + { "host1x", "pll_c",14400, false },
> > + { "disp1", "pll_p",6, false },
> > + { "disp2", "pll_p",6, false },
>
> I think here the parent of disp2 should be "pll_d_out0", not "pll_p".
> Right now pll_p has not a proper clock setting to make 148.5MHz 1080p
> HDMI happy. In addition, you add the 297MHz in pll_d frequency table
> next and I think this is for disp2 has a proper clock rate to support HDMI.
[...]
> > @@ -1051,6 +1053,9 @@ static struct clk_duplicate tegra_clk_duplicates[] = {
> > CLK_DUPLICATE("pll_p_out3", "tegra-i2c.1", "fast-clk"),
> > CLK_DUPLICATE("pll_p_out3", "tegra-i2c.2", "fast-clk"),
> > CLK_DUPLICATE("pll_p_out3", "tegra-i2c.3", "fast-clk"),
> > + CLK_DUPLICATE("pll_p", "tegra-dc.0", "parent"),
> > + CLK_DUPLICATE("pll_p", "tegra-dc.1", "parent"),
> > + CLK_DUPLICATE("pll_d_out0", "tegra-hdmi", "parent"),
> > };
>
> The same with my above comments, the tegra-dc.1's parent should be
> pll_d_out0.
The way this works is that for HDMI it is required that the DC and HDMI
blocks have the same parent. So what really happens is that once you
setup one of the DCs to work with HDMI, its clock will automatically be
reparented to the HDMI parent clock, which in this case is "pll_d_out0".
Thierry
pgpq2RcF9eUbz.pgp
Description: PGP signature
Re: [PATCH v2 1/2] drm: Add NVIDIA Tegra20 support
On Tue, Nov 13, 2012 at 03:15:47PM +0800, Mark Zhang wrote:
> On 11/13/2012 05:55 AM, Thierry Reding wrote:
> > This commit adds a KMS driver for the Tegra20 SoC. This includes basic
> > support for host1x and the two display controllers found on the Tegra20
> > SoC. Each display controller can drive a separate RGB/LVDS output.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > Changes in v2:
> > - drop Linux-specific drm subdirectory for DT bindings documentation
> > - remove display helper leftovers that belong in a later patch
> > - reuse debugfs infrastructure provided by the DRM core
> > - move vblank syncpoint defines to dc.h
> > - use drm_compat_ioctl()
> >
> [...]
> > diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
> > new file mode 100644
> > index 000..be1daf7
> > --- /dev/null
> > +++ b/drivers/gpu/drm/tegra/Kconfig
> > @@ -0,0 +1,23 @@
> > +config DRM_TEGRA
> > + tristate "NVIDIA Tegra DRM"
> > + depends on DRM && OF && ARCH_TEGRA
> > + select DRM_KMS_HELPER
> > + select DRM_GEM_CMA_HELPER
> > + select DRM_KMS_CMA_HELPER
>
> Just for curious, according to my testing, why the "CONFIG_CMA" is not
> enabled while DRM_GEM_CMA_HELPER & DRM_KMS_CMA_HELPER are enabled here?
The reason is that CMA doesn't actually provide any API for drivers to
use and in fact unless you use very large buffers you could indeed run
this code on top of a non-CMA kernel and it will likely even work.
> > +static struct of_device_id tegra_dc_of_match[] = {
> > + { .compatible = "nvidia,tegra20-dc", },
> > + { .compatible = "nvidia,tegra30-dc", },
>
> If you don't want add Tegra 3 support in this patch set, remove
> { .compatible = "nvidia,tegra30-dc", } here.
Good catch! I'll move that into the Tegra30 support patch.
> > +static int host1x_activate_drm_client(struct host1x *host1x,
> > + struct host1x_drm_client *drm,
> > + struct host1x_client *client)
> > +{
> > + mutex_lock(>drm_clients_lock);
> > + list_del_init(>list);
> > + list_add_tail(>list, >drm_active);
>
> Why we need this "drm_active" list? We can combine this function and
> function "host1x_remove_drm_client" and free the drm client just here.
> It's useless after host1x clients registered themselves.
The list is used to properly remove all clients and resources when the
module is unloaded. Granted, this code isn't executed if you don't build
the driver as a loadable module, but it should still be a supported use-
case.
> > +int host1x_unregister_client(struct host1x *host1x,
> > +struct host1x_client *client)
> > +{
> > + struct host1x_drm_client *drm, *tmp;
> > + int err;
> > +
> > + list_for_each_entry_safe(drm, tmp, >drm_active, list) {
> > + if (drm->client == client) {
> > + err = host1x_drm_exit(host1x);
>
> Although this code works but I think it looks confusing.
> "host1x_drm_exit" calls every client's "drm_exit" callback then free all
> the host1x clients, but this function is placed inside a loop.
>
> I think the better way is, free this host1x_client first, then remove it
> from host1x's "clients" list, finally free the host1x(call
> host1x_drm_exit) when the "clients" list get empty.
But that would be the same thing, only slightly more explicit. I find
that the above reads quite well as: look through the list of active
clients and if the client to be removed is in that list, teardown the
DRM part.
I suppose I could add a comment to explain this and avoid confusion.
> > +int tegra_output_init(struct drm_device *drm, struct tegra_output *output)
> > +{
> > + int connector, encoder, err;
> > + enum of_gpio_flags flags;
> > + struct device_node *ddc;
> > + size_t size;
> > +
> > + if (!output->of_node)
> > + output->of_node = output->dev->of_node;
> > +
> > + output->edid = of_get_property(output->of_node, "nvidia,edid",
> > );
> > +
> > + ddc = of_parse_phandle(output->of_node, "nvidia,ddc-i2c-bus", 0);
> > + if (ddc) {
> > + output->ddc = of_find_i2c_adapter_by_node(ddc);
>
> The i2c adapter may not be ready at this time. For Tegra 2, the I2C bus
> for HDMI is not dedicated and we need the i2cmux driver loaded before
> this i2c can be used. It proved that sometimes i2cmux driver loads after
> drm driver.
>
> So we need to add some logics to support driver probe deferral here.
> Anyway, I'm just want you know about this and we can improve this later.
Good point. Unfortunately tegra_output_init() isn't always used from
within .probe(), so it isn't quite easy to handle deferred probe here.
I'll have to take a look at how to solve this properly.
> > +int tegra_dc_rgb_init(struct drm_device *drm, struct tegra_dc *dc)
> > +{
> > + struct device_node *np;
> > + struct tegra_rgb *rgb;
> > + int err;
> >
Re: [PATCH v3 00/13] Win 8 support for digitizers
On Wed, 7 Nov 2012, Benjamin Tissoires wrote: > Hi Guys, > > here is the third version of this patchset. > I think I included most of Henrik's comments. > > Happy reviewing :) > > Cheers, > Benjamin > > v1 introduction: > So, this is an update for supporting Win 8 multitouch devices in the kernel. > As I wanted to reliably forward the resolution, I noticed a bug in the > processing of the unit_exponent in the hid core layer. > Thus the fixes for hid-core and hid-input. > > v2 changes: > * added missing initial patch that prevents the series to be applied on top > of Jiri's tree > * update to include latest hid changes > * taken into account Alan's patch: "hid: put the case in the right switch > statement" > > v3 changes: > * splitted "round return value of hidinput_calc_abs_res" in a separate patch > * export snto32 in hid.h as we need to use it in hid-input.c > * didn't change all drivers, but add a field in hid_usage instead > * add quirk MT_QUIRK_IGNORE_DUPLICATES so that any device can rely on it > * easier understandable support of hovering devices > * changed scan time definition > * applied new definition of scan time in hid-multitouch > * some other few things. Benjamin, thanks for the patchset. I am fine with the HID-specific changes (and I have sent out my Acks to the invidivual patches). For hid-multitouch changes, I'd like to have Reviewed-by: from Henrik as well. Henrik, are you planning to review this patchset, please? Also the note from Dmitry on turning ABS_SCAN_TIME into EV_MSC/MSC_TIMESTAMP should be addressed. Once this is finalized, I'd like to queue this for 3.8 in my tree. Thanks, -- Jiri Kosina SUSE Labs -- 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] mfd: add TI TPS80031 mfd core driver
On Sun, Nov 11, 2012 at 08:42:00PM +0530, Laxman Dewangan wrote:
> +#define TPS80031_RGEMAP_IRQ(_reg, _mask) \
Why RGEMAP_IRQ?
> +static struct regmap_irq_chip tps80031_irq_chip = {
> + .name = "tps80031",
> + .irqs = tps80031_main_irqs,
> + .num_irqs = ARRAY_SIZE(tps80031_main_irqs),
> + .num_regs = 3,
> + .status_base = TPS80031_INT_STS_A,
> + .mask_base = TPS80031_INT_MSK_LINE_A,
> + .wake_base = 1,
I'm not sure your wake_base setting is sane here - this is expected to
be a register. If it is a register why is it not a #define?
> +static int __devinit tps80031_irq_init(struct tps80031 *tps80031, int irq,
> + int irq_base)
> +{
> + struct device *dev = tps80031->dev;
> + int i, ret;
> +
> + for (i = 0; i < 3; i++)
> + tps80031_write(dev, SLAVE_ID2,
> + TPS80031_INT_MSK_STS_A + i, 0x00);
regmap ought to be masking everything for you on init.
signature.asc
Description: Digital signature
[patch] ALSA: es1968: precedence bug in snd_es1968_tea575x_get_pins()
I don't think this works as intended. '|' higher precedence than ?: so the bitwize OR "0 | (val & STR_MOST)" is a no-op. I have re-written it to be more clear. Signed-off-by: Dan Carpenter --- I don't have a way to test this. diff --git a/sound/pci/es1968.c b/sound/pci/es1968.c index 50169bc..7266020 100644 --- a/sound/pci/es1968.c +++ b/sound/pci/es1968.c @@ -2581,9 +2581,14 @@ static u8 snd_es1968_tea575x_get_pins(struct snd_tea575x *tea) struct es1968 *chip = tea->private_data; unsigned long io = chip->io_port + GPIO_DATA; u16 val = inw(io); - - return (val & STR_DATA) ? TEA575X_DATA : 0 | - (val & STR_MOST) ? TEA575X_MOST : 0; + u8 ret; + + ret = 0; + if (val & STR_DATA) + ret |= TEA575X_DATA; + if (val & STR_MOST) + ret |= TEA575X_MOST; + return ret; } static void snd_es1968_tea575x_set_direction(struct snd_tea575x *tea, bool output) -- 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 2/2] ARM: tegra: Add Tegra30 host1x support
On 11/09/2012 09:20 PM, Thierry Reding wrote:
> This commit adds the host1x node along with its children to the Tegra30
> DTSI. Furthermore the OF auxiliary data table is updated to have proper
> names assigned to the platform devices instantiated from the device
> tree. Moreover, the clocks required by host1x and the two display
> controllers are setup and initialized.
>
> Signed-off-by: Thierry Reding
> ---
> arch/arm/boot/dts/tegra30.dtsi| 87
> +++
> arch/arm/mach-tegra/board-dt-tegra30.c| 10
> arch/arm/mach-tegra/tegra30_clocks_data.c | 11 ++--
> 3 files changed, 104 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
> index b8e33c3..529fdb8 100644
> --- a/arch/arm/boot/dts/tegra30.dtsi
> +++ b/arch/arm/boot/dts/tegra30.dtsi
> @@ -4,6 +4,93 @@
> compatible = "nvidia,tegra30";
> interrupt-parent = <>;
>
> + host1x {
> + compatible = "nvidia,tegra30-host1x", "simple-bus";
> + reg = <0x5000 0x00024000>;
> + interrupts = <0 65 0x04 /* mpcore syncpt */
> + 0 67 0x04>; /* mpcore general */
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + ranges = <0x5400 0x5400 0x0400>;
> +
> + mpe {
> + compatible = "nvidia,tegra30-mpe";
> + reg = <0x5404 0x0004>;
> + interrupts = <0 68 0x04>;
> + };
> +
> + vi {
> + compatible = "nvidia,tegra30-vi";
> + reg = <0x5408 0x0004>;
> + interrupts = <0 69 0x04>;
> + };
> +
> + epp {
> + compatible = "nvidia,tegra30-epp";
> + reg = <0x540c 0x0004>;
> + interrupts = <0 70 0x04>;
> + };
> +
> + isp {
> + compatible = "nvidia,tegra30-isp";
> + reg = <0x5410 0x0004>;
> + interrupts = <0 71 0x04>;
> + };
> +
> + gr2d {
> + compatible = "nvidia,tegra30-gr2d";
> + reg = <0x5414 0x0004>;
> + interrupts = <0 72 0x04>;
> + };
> +
> + gr3d {
> + compatible = "nvidia,tegra30-gr3d";
> + reg = <0x5418 0x0004>;
> + };
> +
> + dc@5420 {
> + compatible = "nvidia,tegra30-dc";
> + reg = <0x5420 0x0004>;
> + interrupts = <0 73 0x04>;
> +
> + rgb {
> + status = "disabled";
> + };
> + };
> +
> + dc@5424 {
> + compatible = "nvidia,tegra30-dc";
> + reg = <0x5424 0x0004>;
> + interrupts = <0 74 0x04>;
> +
> + rgb {
> + status = "disabled";
> + };
> + };
> +
> + hdmi {
> + compatible = "nvidia,tegra30-hdmi";
> + reg = <0x5428 0x0004>;
> + interrupts = <0 75 0x04>;
> + status = "disabled";
> + };
> +
> + tvo {
> + compatible = "nvidia,tegra30-tvo";
> + reg = <0x542c 0x0004>;
> + interrupts = <0 76 0x04>;
> + status = "disabled";
> + };
> +
> + dsi {
> + compatible = "nvidia,tegra30-dsi";
> + reg = <0x5430 0x0004>;
> + status = "disabled";
> + };
> + };
> +
> timer@50004600 {
> compatible = "arm,cortex-a9-twd-timer";
> reg = <0x50040600 0x20>;
> diff --git a/arch/arm/mach-tegra/board-dt-tegra30.c
> b/arch/arm/mach-tegra/board-dt-tegra30.c
> index cd30338..ff21107 100644
> --- a/arch/arm/mach-tegra/board-dt-tegra30.c
> +++ b/arch/arm/mach-tegra/board-dt-tegra30.c
> @@ -57,6 +57,12 @@ struct of_dev_auxdata tegra30_auxdata_lookup[] __initdata
> = {
> OF_DEV_AUXDATA("nvidia,tegra30-slink", 0x7000DA00, "spi_tegra.3",
> NULL),
> OF_DEV_AUXDATA("nvidia,tegra30-slink", 0x7000DC00, "spi_tegra.4",
> NULL),
> OF_DEV_AUXDATA("nvidia,tegra30-slink", 0x7000DE00, "spi_tegra.5",
> NULL),
> + OF_DEV_AUXDATA("nvidia,tegra30-host1x", 0x5000, "tegra-host1x",
> NULL),
> + OF_DEV_AUXDATA("nvidia,tegra30-dc", 0x5420, "tegra-dc.0", NULL),
> + OF_DEV_AUXDATA("nvidia,tegra30-dc",
Re: [PATCH v3 01/13] HID: hid-input: export hidinput_calc_abs_res
On Wed, 7 Nov 2012, Benjamin Tissoires wrote:
> Exporting the function allows us to calculate the resolution in third
> party drivers like hid-multitouch.
> This patch also complete the function with additional valid axes.
>
> Signed-off-by: Benjamin Tissoires
Acked-by: Jiri Kosina
> ---
> drivers/hid/hid-input.c | 9 -
> drivers/hid/hid-multitouch.c | 1 +
> include/linux/hid.h | 1 +
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 10248cf..f5b1d57 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -208,7 +208,7 @@ static int hidinput_setkeycode(struct input_dev *dev,
> * Only exponent 1 length units are processed. Centimeters and inches are
> * converted to millimeters. Degrees are converted to radians.
> */
> -static __s32 hidinput_calc_abs_res(const struct hid_field *field, __u16 code)
> +__s32 hidinput_calc_abs_res(const struct hid_field *field, __u16 code)
> {
> __s32 unit_exponent = field->unit_exponent;
> __s32 logical_extents = field->logical_maximum -
> @@ -229,6 +229,12 @@ static __s32 hidinput_calc_abs_res(const struct
> hid_field *field, __u16 code)
> case ABS_X:
> case ABS_Y:
> case ABS_Z:
> + case ABS_MT_POSITION_X:
> + case ABS_MT_POSITION_Y:
> + case ABS_MT_TOOL_X:
> + case ABS_MT_TOOL_Y:
> + case ABS_MT_TOUCH_MAJOR:
> + case ABS_MT_TOUCH_MINOR:
> if (field->unit == 0x11) { /* If centimeters */
> /* Convert to millimeters */
> unit_exponent += 1;
> @@ -283,6 +289,7 @@ static __s32 hidinput_calc_abs_res(const struct hid_field
> *field, __u16 code)
> /* Calculate resolution */
> return logical_extents / physical_extents;
> }
> +EXPORT_SYMBOL_GPL(hidinput_calc_abs_res);
>
> #ifdef CONFIG_HID_BATTERY_STRENGTH
> static enum power_supply_property hidinput_battery_props[] = {
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 3eb02b9..9f64e36 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -298,6 +298,7 @@ static void set_abs(struct input_dev *input, unsigned int
> code,
> int fmax = field->logical_maximum;
> int fuzz = snratio ? (fmax - fmin) / snratio : 0;
> input_set_abs_params(input, code, fmin, fmax, fuzz, 0);
> + input_abs_set_res(input, code, hidinput_calc_abs_res(field, code));
> }
>
> static void mt_store_field(struct hid_usage *usage, struct mt_device *td,
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 7e1f37d..9edb06c 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -743,6 +743,7 @@ int hid_input_report(struct hid_device *, int type, u8 *,
> int, int);
> int hidinput_find_field(struct hid_device *hid, unsigned int type, unsigned
> int code, struct hid_field **field);
> struct hid_field *hidinput_get_led_field(struct hid_device *hid);
> unsigned int hidinput_count_leds(struct hid_device *hid);
> +__s32 hidinput_calc_abs_res(const struct hid_field *field, __u16 code);
> void hid_output_report(struct hid_report *report, __u8 *data);
> struct hid_device *hid_allocate_device(void);
> struct hid_report *hid_register_report(struct hid_device *device, unsigned
> type, unsigned id);
> --
> 1.7.11.7
>
--
Jiri Kosina
SUSE Labs
--
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] ARM: tegra: Add Tegra20 host1x support
On 11/09/2012 09:20 PM, Thierry Reding wrote:
> This commit adds the host1x node along with its children to the Tegra20
> DTSI. Furthermore the OF auxiliary data table is updated to have proper
> names assigned to the platform devices instantiated from the device
> tree. Moreover, the clocks required by host1x and the two display
> controllers are initialized and the pll_d frequency table is completed
> with a few entries to support common HDMI and LVDS display modes.
>
> Signed-off-by: Thierry Reding
> ---
> arch/arm/boot/dts/tegra20.dtsi| 87
> +++
> arch/arm/mach-tegra/board-dt-tegra20.c| 9
> arch/arm/mach-tegra/tegra20_clocks_data.c | 23
> 3 files changed, 110 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
> index 71a650d..2b4dec9 100644
> --- a/arch/arm/boot/dts/tegra20.dtsi
> +++ b/arch/arm/boot/dts/tegra20.dtsi
> @@ -4,6 +4,93 @@
> compatible = "nvidia,tegra20";
> interrupt-parent = <>;
>
> + host1x {
> + compatible = "nvidia,tegra20-host1x", "simple-bus";
> + reg = <0x5000 0x00024000>;
> + interrupts = <0 65 0x04 /* mpcore syncpt */
> + 0 67 0x04>; /* mpcore general */
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + ranges = <0x5400 0x5400 0x0400>;
> +
> + mpe {
> + compatible = "nvidia,tegra20-mpe";
> + reg = <0x5404 0x0004>;
> + interrupts = <0 68 0x04>;
> + };
> +
> + vi {
> + compatible = "nvidia,tegra20-vi";
> + reg = <0x5408 0x0004>;
> + interrupts = <0 69 0x04>;
> + };
> +
> + epp {
> + compatible = "nvidia,tegra20-epp";
> + reg = <0x540c 0x0004>;
> + interrupts = <0 70 0x04>;
> + };
> +
> + isp {
> + compatible = "nvidia,tegra20-isp";
> + reg = <0x5410 0x0004>;
> + interrupts = <0 71 0x04>;
> + };
> +
> + gr2d {
> + compatible = "nvidia,tegra20-gr2d";
> + reg = <0x5414 0x0004>;
> + interrupts = <0 72 0x04>;
> + };
> +
> + gr3d {
> + compatible = "nvidia,tegra20-gr3d";
> + reg = <0x5418 0x0004>;
> + };
> +
> + dc@5420 {
> + compatible = "nvidia,tegra20-dc";
> + reg = <0x5420 0x0004>;
> + interrupts = <0 73 0x04>;
> +
> + rgb {
> + status = "disabled";
> + };
> + };
> +
> + dc@5424 {
> + compatible = "nvidia,tegra20-dc";
> + reg = <0x5424 0x0004>;
> + interrupts = <0 74 0x04>;
> +
> + rgb {
> + status = "disabled";
> + };
> + };
> +
> + hdmi {
> + compatible = "nvidia,tegra20-hdmi";
> + reg = <0x5428 0x0004>;
> + interrupts = <0 75 0x04>;
> + status = "disabled";
> + };
> +
> + tvo {
> + compatible = "nvidia,tegra20-tvo";
> + reg = <0x542c 0x0004>;
> + interrupts = <0 76 0x04>;
> + status = "disabled";
> + };
> +
> + dsi {
> + compatible = "nvidia,tegra20-dsi";
> + reg = <0x5430 0x0004>;
> + status = "disabled";
> + };
> + };
> +
> timer@50004600 {
> compatible = "arm,cortex-a9-twd-timer";
> reg = <0x50040600 0x20>;
> diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
> b/arch/arm/mach-tegra/board-dt-tegra20.c
> index 22f5a9b..1afbdd1 100644
> --- a/arch/arm/mach-tegra/board-dt-tegra20.c
> +++ b/arch/arm/mach-tegra/board-dt-tegra20.c
> @@ -93,6 +93,12 @@ struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata
> = {
> OF_DEV_AUXDATA("nvidia,tegra20-slink", 0x7000D600, "spi_tegra.1",
> NULL),
> OF_DEV_AUXDATA("nvidia,tegra20-slink", 0x7000D800, "spi_tegra.2",
> NULL),
> OF_DEV_AUXDATA("nvidia,tegra20-slink", 0x7000DA00, "spi_tegra.3",
> NULL),
> + OF_DEV_AUXDATA("nvidia,tegra20-host1x", 0x5000, "tegra-host1x",
> NULL),
> +
[patch] mips, arc: fix build failure
Using a cross-compiler to fix another issue, the following build error occurred for mips defconfig: arch/mips/fw/arc/misc.c: In function 'ArcHalt': arch/mips/fw/arc/misc.c:25:2: error: implicit declaration of function 'local_irq_disable' Fix it up by including irqflags.h. Signed-off-by: David Rientjes --- arch/mips/fw/arc/misc.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/fw/arc/misc.c b/arch/mips/fw/arc/misc.c --- a/arch/mips/fw/arc/misc.c +++ b/arch/mips/fw/arc/misc.c @@ -11,6 +11,7 @@ */ #include #include +#include #include -- 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 02/13] HID: hid-input: round return value of hidinput_calc_abs_res
On Wed, 7 Nov 2012, Benjamin Tissoires wrote: > hidinput_calc_abs_res should return the closest int in the division > instead of the floor. > On a device with a logical_max of 3008 and a physical_max of 255mm, > previous implementation gave a resolution of 11 instead of 12. > With 11, user-space computes a physical size of 273.5mm and the > round_closest results gives 250.6mm. > The old implementation introduced an error of 2cm in this example. > > Signed-off-by: Benjamin Tissoires Acked-by: Jiri Kosina > --- > drivers/hid/hid-input.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c > index f5b1d57..67044f3 100644 > --- a/drivers/hid/hid-input.c > +++ b/drivers/hid/hid-input.c > @@ -287,7 +287,7 @@ __s32 hidinput_calc_abs_res(const struct hid_field > *field, __u16 code) > } > > /* Calculate resolution */ > - return logical_extents / physical_extents; > + return DIV_ROUND_CLOSEST(logical_extents, physical_extents); > } > EXPORT_SYMBOL_GPL(hidinput_calc_abs_res); > > -- > 1.7.11.7 > -- Jiri Kosina SUSE Labs -- 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 04/13] HID: hid-input: add usage_index in struct hid_usage.
On Wed, 7 Nov 2012, Benjamin Tissoires wrote:
> Currently, there is no way to know the index of the current field
> in the .input_mapping and .event callbacks when this field is inside
> an array of HID fields.
> This patch adds this index to the struct hid_usage so that this
> information is available to input_mapping and event callbacks.
>
> Signed-off-by: Benjamin Tissoires
Acked-by: Jiri Kosina
> ---
> drivers/hid/hid-core.c | 4
> include/linux/hid.h| 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 9da3007..8f82c4c 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -92,6 +92,7 @@ EXPORT_SYMBOL_GPL(hid_register_report);
> static struct hid_field *hid_register_field(struct hid_report *report,
> unsigned usages, unsigned values)
> {
> struct hid_field *field;
> + int i;
>
> if (report->maxfield == HID_MAX_FIELDS) {
> hid_err(report->device, "too many fields in report\n");
> @@ -110,6 +111,9 @@ static struct hid_field *hid_register_field(struct
> hid_report *report, unsigned
> field->value = (s32 *)(field->usage + usages);
> field->report = report;
>
> + for (i = 0; i < usages; i++)
> + field->usage[i].usage_index = i;
> +
> return field;
> }
>
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index a110a3e..6b4f322 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -380,6 +380,7 @@ struct hid_usage {
> unsigned hid; /* hid usage code */
> unsigned collection_index; /* index into collection array */
> /* hidinput data */
> + unsigned usage_index; /* index into usage array */
> __u16 code; /* input driver code */
> __u8 type; /* input driver type */
> __s8 hat_min; /* hat switch fun */
> --
> 1.7.11.7
>
--
Jiri Kosina
SUSE Labs
--
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 03/13] HID: core: fix unit exponent parsing
On Wed, 7 Nov 2012, Benjamin Tissoires wrote:
> HID spec details special values for the HID field unit exponent.
> Basically, the range [0x8..0xf] correspond to [-8..-1], so this is
> a standard two's complement on a half-byte.
>
> Signed-off-by: Benjamin Tissoires
Acked-by: Jiri Kosina
> ---
> drivers/hid/hid-core.c | 16 +++-
> drivers/hid/hid-input.c | 13 +
> include/linux/hid.h | 1 +
> 3 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 3d0da29..9da3007 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -315,6 +315,7 @@ static s32 item_sdata(struct hid_item *item)
>
> static int hid_parser_global(struct hid_parser *parser, struct hid_item
> *item)
> {
> + __u32 raw_value;
> switch (item->tag) {
> case HID_GLOBAL_ITEM_TAG_PUSH:
>
> @@ -365,7 +366,14 @@ static int hid_parser_global(struct hid_parser *parser,
> struct hid_item *item)
> return 0;
>
> case HID_GLOBAL_ITEM_TAG_UNIT_EXPONENT:
> - parser->global.unit_exponent = item_sdata(item);
> + /* Units exponent negative numbers are given through a
> + * two's complement.
> + * See "6.2.2.7 Global Items" for more information. */
> + raw_value = item_udata(item);
> + if (!(raw_value & 0xfff0))
> + parser->global.unit_exponent = hid_snto32(raw_value, 4);
> + else
> + parser->global.unit_exponent = raw_value;
> return 0;
>
> case HID_GLOBAL_ITEM_TAG_UNIT:
> @@ -865,6 +873,12 @@ static s32 snto32(__u32 value, unsigned n)
> return value & (1 << (n - 1)) ? value | (-1 << n) : value;
> }
>
> +s32 hid_snto32(__u32 value, unsigned n)
> +{
> + return snto32(value, n);
> +}
> +EXPORT_SYMBOL_GPL(hid_snto32);
> +
> /*
> * Convert a signed 32-bit integer to a signed n-bit integer.
> */
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 67044f3..7015080 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -192,7 +192,6 @@ static int hidinput_setkeycode(struct input_dev *dev,
> return -EINVAL;
> }
>
> -
> /**
> * hidinput_calc_abs_res - calculate an absolute axis resolution
> * @field: the HID report field to calculate resolution for
> @@ -235,17 +234,23 @@ __s32 hidinput_calc_abs_res(const struct hid_field
> *field, __u16 code)
> case ABS_MT_TOOL_Y:
> case ABS_MT_TOUCH_MAJOR:
> case ABS_MT_TOUCH_MINOR:
> - if (field->unit == 0x11) { /* If centimeters */
> + if (field->unit & 0xff00) /* Not a length */
> + return 0;
> + unit_exponent += hid_snto32(field->unit >> 4, 4) - 1;
> + switch (field->unit & 0xf) {
> + case 0x1: /* If centimeters */
> /* Convert to millimeters */
> unit_exponent += 1;
> - } else if (field->unit == 0x13) { /* If inches */
> + break;
> + case 0x3: /* If inches */
> /* Convert to millimeters */
> prev = physical_extents;
> physical_extents *= 254;
> if (physical_extents < prev)
> return 0;
> unit_exponent -= 1;
> - } else {
> + break;
> + default:
> return 0;
> }
> break;
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 9edb06c..a110a3e 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -754,6 +754,7 @@ int hid_connect(struct hid_device *hid, unsigned int
> connect_mask);
> void hid_disconnect(struct hid_device *hid);
> const struct hid_device_id *hid_match_id(struct hid_device *hdev,
>const struct hid_device_id *id);
> +s32 hid_snto32(__u32 value, unsigned n);
>
> /**
> * hid_map_usage - map usage input bits
> --
> 1.7.11.7
>
--
Jiri Kosina
SUSE Labs
--
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] MM: Support more pagesizes for MAP_HUGETLB/SHM_HUGETLB v7 fix fix fix fix
Move the definitions of MAP_HUGE_SHIFT and MAP_HUGE_MASK to mman-common.h and fixup the architectures which do not use that file to fix the following build failure: mm/mmap.c: In function 'SYSC_mmap_pgoff': mm/mmap.c:1271:15: error: 'MAP_HUGE_SHIFT' undeclared (first use in this function) mm/mmap.c:1271:15: note: each undeclared identifier is reported only once for each function it appears in mm/mmap.c:1271:33: error: 'MAP_HUGE_MASK' undeclared (first use in this function) Tested on alpha, hppa, ia64, mips, powerpc, sparc, and x86. Signed-off-by: David Rientjes --- arch/alpha/include/asm/mman.h | 11 +++ arch/mips/include/uapi/asm/mman.h | 11 +++ arch/parisc/include/uapi/asm/mman.h| 11 +++ arch/xtensa/include/uapi/asm/mman.h| 11 +++ include/uapi/asm-generic/mman-common.h | 11 +++ include/uapi/asm-generic/mman.h| 13 + 6 files changed, 56 insertions(+), 12 deletions(-) diff --git a/arch/alpha/include/asm/mman.h b/arch/alpha/include/asm/mman.h --- a/arch/alpha/include/asm/mman.h +++ b/arch/alpha/include/asm/mman.h @@ -63,4 +63,15 @@ /* compatibility flags */ #define MAP_FILE 0 +/* + * When MAP_HUGETLB is set bits [26:31] encode the log2 of the huge page size. + * This gives us 6 bits, which is enough until someone invents 128 bit address + * spaces. + * + * Assume these are all power of twos. + * When 0 use the default page size. + */ +#define MAP_HUGE_SHIFT 26 +#define MAP_HUGE_MASK 0x3f + #endif /* __ALPHA_MMAN_H__ */ diff --git a/arch/mips/include/uapi/asm/mman.h b/arch/mips/include/uapi/asm/mman.h --- a/arch/mips/include/uapi/asm/mman.h +++ b/arch/mips/include/uapi/asm/mman.h @@ -87,4 +87,15 @@ /* compatibility flags */ #define MAP_FILE 0 +/* + * When MAP_HUGETLB is set bits [26:31] encode the log2 of the huge page size. + * This gives us 6 bits, which is enough until someone invents 128 bit address + * spaces. + * + * Assume these are all power of twos. + * When 0 use the default page size. + */ +#define MAP_HUGE_SHIFT 26 +#define MAP_HUGE_MASK 0x3f + #endif /* _ASM_MMAN_H */ diff --git a/arch/parisc/include/uapi/asm/mman.h b/arch/parisc/include/uapi/asm/mman.h --- a/arch/parisc/include/uapi/asm/mman.h +++ b/arch/parisc/include/uapi/asm/mman.h @@ -70,4 +70,15 @@ #define MAP_FILE 0 #define MAP_VARIABLE 0 +/* + * When MAP_HUGETLB is set bits [26:31] encode the log2 of the huge page size. + * This gives us 6 bits, which is enough until someone invents 128 bit address + * spaces. + * + * Assume these are all power of twos. + * When 0 use the default page size. + */ +#define MAP_HUGE_SHIFT 26 +#define MAP_HUGE_MASK 0x3f + #endif /* __PARISC_MMAN_H__ */ diff --git a/arch/xtensa/include/uapi/asm/mman.h b/arch/xtensa/include/uapi/asm/mman.h --- a/arch/xtensa/include/uapi/asm/mman.h +++ b/arch/xtensa/include/uapi/asm/mman.h @@ -93,4 +93,15 @@ /* compatibility flags */ #define MAP_FILE 0 +/* + * When MAP_HUGETLB is set bits [26:31] encode the log2 of the huge page size. + * This gives us 6 bits, which is enough until someone invents 128 bit address + * spaces. + * + * Assume these are all power of twos. + * When 0 use the default page size. + */ +#define MAP_HUGE_SHIFT 26 +#define MAP_HUGE_MASK 0x3f + #endif /* _XTENSA_MMAN_H */ diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h --- a/include/uapi/asm-generic/mman-common.h +++ b/include/uapi/asm-generic/mman-common.h @@ -55,4 +55,15 @@ /* compatibility flags */ #define MAP_FILE 0 +/* + * When MAP_HUGETLB is set bits [26:31] encode the log2 of the huge page size. + * This gives us 6 bits, which is enough until someone invents 128 bit address + * spaces. + * + * Assume these are all power of twos. + * When 0 use the default page size. + */ +#define MAP_HUGE_SHIFT 26 +#define MAP_HUGE_MASK 0x3f + #endif /* __ASM_GENERIC_MMAN_COMMON_H */ diff --git a/include/uapi/asm-generic/mman.h b/include/uapi/asm-generic/mman.h --- a/include/uapi/asm-generic/mman.h +++ b/include/uapi/asm-generic/mman.h @@ -13,18 +13,7 @@ #define MAP_STACK 0x2 /* give out an address that is best suited for process/thread stacks */ #define MAP_HUGETLB0x4 /* create a huge page mapping */ -/* Bits [26:31] are reserved */ - -/* - * When MAP_HUGETLB is set bits [26:31] encode the log2 of the huge page size. - * This gives us 6 bits, which is enough until someone invents 128 bit address - * spaces. - * - * Assume these are all power of twos. - * When 0 use the default page size. - */ -#define MAP_HUGE_SHIFT 26 -#define MAP_HUGE_MASK 0x3f +/* Bits [26:31] are reserved, see mman-common.h for MAP_HUGETLB usage */ #define MCL_CURRENT1 /* lock all current mappings */ #define MCL_FUTURE 2 /* lock all future mappings */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of
Re: [patch 3/7] fs, notify: Add file handle entry into inotify_inode_mark
On Tue, 13 Nov 2012 11:20:57 +0400 Cyrill Gorcunov wrote:
> > > struct inotify_inode_mark {
> > > struct fsnotify_mark fsn_mark;
> > > int wd;
> > > +#ifdef INOTIFY_USE_FHANDLE
> > > + __u8 fhandle[sizeof(struct file_handle) + MAX_HANDLE_SZ];
> > > +#endif
> > > };
> >
> > Whoa. This adds 128+8 bytes to the inotify_inode_mark. That's a lot of
> > bloat, and there can be a lot of inotify_inode_mark's in the system?
>
> Yes, that's why it's not turned on by default, only if is c/r turned on.
> iirc I've been said that usually only about 40 bytes is used (in the tests
> I met only 8 bytes). Letme re-check all things.
The question is, how many `struct inotify_inode_mark's are instantiated
system-wide? Could be millions?
Dumb question: do we really need inotify_inode_mark.fhandle at all?
What prevents us from assembling this info on demand when ->show_fdinfo() is
called?
--
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] ARM: tegra: Add Tegra20 host1x support
On 11/13/2012 02:41 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Nov 13, 2012 at 12:38:34PM +0800, Mark Zhang wrote:
>> On 11/12/2012 05:39 PM, Mark Zhang wrote:
>>> On 11/09/2012 09:20 PM, Thierry Reding wrote:
> [...]
@@ -1036,9 +1041,6 @@ static struct clk_duplicate tegra_clk_duplicates[] =
{
CLK_DUPLICATE("usbd", "utmip-pad",NULL),
CLK_DUPLICATE("usbd", "tegra-ehci.0", NULL),
CLK_DUPLICATE("usbd", "tegra-otg",NULL),
- CLK_DUPLICATE("hdmi", "tegradc.0","hdmi"),
- CLK_DUPLICATE("hdmi", "tegradc.1","hdmi"),
- CLK_DUPLICATE("host1x", "tegra_grhost", "host1x"),
CLK_DUPLICATE("2d", "tegra_grhost", "gr2d"),
CLK_DUPLICATE("3d", "tegra_grhost", "gr3d"),
CLK_DUPLICATE("epp","tegra_grhost", "epp"),
@@ -1051,6 +1053,9 @@ static struct clk_duplicate tegra_clk_duplicates[] =
{
CLK_DUPLICATE("pll_p_out3", "tegra-i2c.1", "fast-clk"),
CLK_DUPLICATE("pll_p_out3", "tegra-i2c.2", "fast-clk"),
CLK_DUPLICATE("pll_p_out3", "tegra-i2c.3", "fast-clk"),
+ CLK_DUPLICATE("pll_p", "tegra-dc.0", "parent"),
+ CLK_DUPLICATE("pll_p", "tegra-dc.1", "parent"),
+ CLK_DUPLICATE("pll_d_out0", "tegra-hdmi", "parent"),
};
>>
>> Why we need this "CLK_DUPLICATE"? Set the clock parent of the dc
>> controllers to pll_p?
>
> This was the method proposed by Stephen to abstract away the clock tree
> differences between Tegra20 and Tegra30. The way this works is that we
> can {devm_,}clk_get(>dev, "parent") in the display and HDMI
> controllers' .probe() and it'll obtain the correct parent clock
> independent of which version of Tegra is used.
>
Yes, after reading the corresponding codes in rgb.c & hdmi.c, I got how
this works. It's better than our previous version, I mean, the version
which we hard-code the clock parent setting logics in clock.c. But I
wanna say, it looks weird if you don't read the code of drm driver.
> Thierry
>
> * Unknown Key
> * 0x7F3EB3A1
>
--
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 v4 5/9] kernel: padata : use __this_cpu_read per-cpu helper
On Tue, Nov 13, 2012 at 08:27:03AM +0100, Steffen Klassert wrote: > On Tue, Nov 13, 2012 at 09:52:33AM +0800, Shan Wei wrote: > > From: Shan Wei > > > > For bottom halves off, __this_cpu_read is better. > > > > Signed-off-by: Shan Wei > > Reviewed-by: Christoph Lameter > > Acked-by: Steffen Klassert > > Herbert, are you going to take this one? Thanks Steffen, I'll apply his patch. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] Add missing license for ioapic module.
>>> On 13.11.12 at 05:39, Andrew Cooks wrote:
> config PCI_IOAPIC turned into a tristate in commit
> b95a7bd700466c10fda84acbd33f70cf66ec91ce, but no module license is specified.
> This adds the missing module license.
>
> Signed-off-by: Andrew Cooks
Acked-by: Jan Beulich
> ---
> drivers/pci/ioapic.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/ioapic.c b/drivers/pci/ioapic.c
> index 205af8d..22436f7 100644
> --- a/drivers/pci/ioapic.c
> +++ b/drivers/pci/ioapic.c
> @@ -125,3 +125,5 @@ static void __exit ioapic_exit(void)
>
> module_init(ioapic_init);
> module_exit(ioapic_exit);
> +
> +MODULE_LICENSE("GPL");
> --
> 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] pinctrl: spear: Fix the logic of setting reg in pmx_init_gpio_pingroup_addr
Current code does not work if count > 1, fix it.
Signed-off-by: Axel Lin
---
drivers/pinctrl/spear/pinctrl-spear.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/spear/pinctrl-spear.c
b/drivers/pinctrl/spear/pinctrl-spear.c
index f9483ae..107780c 100644
--- a/drivers/pinctrl/spear/pinctrl-spear.c
+++ b/drivers/pinctrl/spear/pinctrl-spear.c
@@ -86,10 +86,10 @@ void __devinit
pmx_init_gpio_pingroup_addr(struct spear_gpio_pingroup *gpio_pingroup,
unsigned count, u16 reg)
{
- int i = 0, j = 0;
+ int i, j;
- for (; i < count; i++)
- for (; j < gpio_pingroup[i].nmuxregs; j++)
+ for (i = 0; i < count; i++)
+ for (j = 0; j < gpio_pingroup[i].nmuxregs; j++)
gpio_pingroup[i].muxregs[j].reg = reg;
}
--
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/
[PATCH v6] create sun sysfs file
Hi Rafael,
The patch was rebased on linux-next. Ant it has been acked by Len:
https://lkml.org/lkml/2012/10/10/65
So please merge it into your tree.
---
_SUN method provides the slot unique-ID in the ACPI namespace. And The value
is written in Advanced Configuration and Power Interface Specification as
follows:
"The _SUN value is required to be unique among the slots ofthe same type.
It is also recommended that this number match the slot number printed on
the physical slot whenever possible."
So if we can know the value, we can identify the physical position of the
slot in the system.
The patch creates "sun" file in sysfs for identifying physical position
of the slot.
Reviewed-by: Toshi Kani
Signed-off-by: Yasuaki Ishimatsu
---
Documentation/ABI/testing/sysfs-devices-sun | 14 ++
drivers/acpi/scan.c | 24
include/acpi/acpi_bus.h |1 +
3 files changed, 39 insertions(+)
Index: linux-next/include/acpi/acpi_bus.h
===
--- linux-next.orig/include/acpi/acpi_bus.h 2012-11-12 17:58:08.0
+0900
+++ linux-next/include/acpi/acpi_bus.h 2012-11-12 19:07:33.577427071 +0900
@@ -179,6 +179,7 @@ struct acpi_device_pnp {
acpi_device_name device_name; /* Driver-determined */
acpi_device_class device_class; /*" */
union acpi_object *str_obj; /* unicode string for _STR method */
+ unsigned long sun; /* _SUN */
};
#define acpi_device_bid(d) ((d)->pnp.bus_id)
Index: linux-next/drivers/acpi/scan.c
===
--- linux-next.orig/drivers/acpi/scan.c 2012-11-12 17:57:44.0 +0900
+++ linux-next/drivers/acpi/scan.c 2012-11-12 19:08:53.387428254 +0900
@@ -292,11 +292,21 @@ static ssize_t description_show(struct d
}
static DEVICE_ATTR(description, 0444, description_show, NULL);
+static ssize_t
+acpi_device_sun_show(struct device *dev, struct device_attribute *attr,
+char *buf) {
+ struct acpi_device *acpi_dev = to_acpi_device(dev);
+
+ return sprintf(buf, "%lu\n", acpi_dev->pnp.sun);
+}
+static DEVICE_ATTR(sun, 0444, acpi_device_sun_show, NULL);
+
static int acpi_device_setup_files(struct acpi_device *dev)
{
struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
acpi_status status;
acpi_handle temp;
+ unsigned long long sun;
int result = 0;
/*
@@ -338,6 +348,16 @@ static int acpi_device_setup_files(struc
if (dev->pnp.unique_id)
result = device_create_file(>dev, _attr_uid);
+ status = acpi_evaluate_integer(dev->handle, "_SUN", NULL, );
+ if (ACPI_SUCCESS(status)) {
+ dev->pnp.sun = (unsigned long)sun;
+ result = device_create_file(>dev, _attr_sun);
+ if (result)
+ goto end;
+ } else {
+ dev->pnp.sun = (unsigned long)-1;
+ }
+
/*
* If device has _EJ0, 'eject' file is created that is used to trigger
* hot-removal function from userland.
@@ -369,6 +389,10 @@ static void acpi_device_remove_files(str
if (ACPI_SUCCESS(status))
device_remove_file(>dev, _attr_eject);
+ status = acpi_get_handle(dev->handle, "_SUN", );
+ if (ACPI_SUCCESS(status))
+ device_remove_file(>dev, _attr_sun);
+
if (dev->pnp.unique_id)
device_remove_file(>dev, _attr_uid);
if (dev->flags.bus_address)
Index: linux-next/Documentation/ABI/testing/sysfs-devices-sun
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-next/Documentation/ABI/testing/sysfs-devices-sun 2012-11-12
19:09:26.854428750 +0900
@@ -0,0 +1,14 @@
+Whatt: /sys/devices/.../sun
+Date: October 2012
+Contact: Yasuaki Ishimatsu
+Description:
+ The file contains a Slot-unique ID which provided by the _SUN
+ method in the ACPI namespace. The value is written in Advanced
+ Configuration and Power Interface Specification as follows:
+
+ "The _SUN value is required to be unique among the slots of
+ the same type. It is also recommended that this number match
+ the slot number printed on the physical slot whenever possible."
+
+ So reading the sysfs file, we can identify a physical position
+ of the slot in the system.
--
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 v4 5/9] kernel: padata : use __this_cpu_read per-cpu helper
On Tue, Nov 13, 2012 at 09:52:33AM +0800, Shan Wei wrote: > From: Shan Wei > > For bottom halves off, __this_cpu_read is better. > > Signed-off-by: Shan Wei > Reviewed-by: Christoph Lameter Acked-by: Steffen Klassert Herbert, are you going to take this 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 0/8] Announcement: Enhanced NUMA scheduling with adaptive affinity
* Christoph Lameter wrote: > On Mon, 12 Nov 2012, Peter Zijlstra wrote: > > > The biggest conceptual addition, beyond the elimination of > > the home node, is that the scheduler is now able to > > recognize 'private' versus 'shared' pages, by carefully > > analyzing the pattern of how CPUs touch the working set > > pages. The scheduler automatically recognizes tasks that > > share memory with each other (and make dominant use of that > > memory) - versus tasks that allocate and use their working > > set privately. > > That is a key distinction to make and if this really works > then that is major progress. I posted updated benchmark results yesterday, and the approach is indeed a performance breakthrough: http://lkml.org/lkml/2012/11/12/330 It also made the code more generic and more maintainable from a scheduler POV. > > This new scheduler code is then able to group tasks that are > > "memory related" via their memory access patterns together: > > in the NUMA context moving them on the same node if > > possible, and spreading them amongst nodes if they use > > private memory. > > What happens if processes memory accesses are related but the > common set of data does not fit into the memory provided by a > single node? The other (very common) node-overload case is that there are more tasks for a shared piece of memory than fits on a single node. I have measured two such workloads, one is the Java SPEC benchmark: v3.7-vanilla: 494828 transactions/sec v3.7-NUMA:627228 transactions/sec[ +26.7% ] the other is the 'numa01' testcase of autonumabench: v3.7-vanilla: 340.3 seconds v3.7-NUMA: 216.9 seconds [ +56% ] > The correct resolution usually is in that case to interleasve > the pages over both nodes in use. I'd not go as far as to claim that to be a general rule: the correct placement depends on the system and workload specifics: how much memory is on each node, how many tasks run on each node, and whether the access patterns and working set of the tasks is symmetric amongst each other - which is not a given at all. Say consider a database server that executes small and large queries over a large, memory-shared database, and has worker tasks to clients, to serve each query. Depending on the nature of the queries, interleaving can easily be the wrong thing to do. Thanks, Ingo -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Mon, Nov 12, 2012 at 10:22:07PM -0700, Stephen Warren wrote:
> On 11/12/2012 06:05 PM, David Gibson wrote:
> > On Fri, Nov 09, 2012 at 09:42:37PM +, Grant Likely wrote:
> ...
> > 2) graft bundle
> >
> > The base tree has something like this:
> >
> > ...
> > i2c@XXX {
> > ...
> > cape-socket {
> > compatible = "vendor,cape-socket";
> > id = "Socket-A";
> > piece-id = "i2c";
> > ranges = < ... >;
> > };
> > };
> > ...
> > spi@YYY {
> > ...
> > cape-socket {
> > compatible = "vendor,cape-socket";
> > id = "Socket-A";
> > piece-id = "spi";
> > ranges = < ... >;
> > };
> > };
> > ...
> > cape-socket {
> > compatible = "vendor,cape-socket";
> > id = "Socket-A";
> > piece-id = "misc";
> > interrupt-map = < ... >;
> > interrupt-map-mask = < ... >;
> > gpio-map = < ... >;
> > gpio-map-mask = < ... >;
> > };
> >
> > Then instead of grafting a single subtree for the socket, we install a
> > "bundle" of subtrees, one each for each of the pieces within the
> > socket. That bundle could either be an actual set of multiple fdts,
> > or they could be placed into one fdt with a dummy root node, something like:
> >
> > / {
> > plugin-bundle;
> > compatible = "vendor,cape-plugin";
> > version = ...;
> > i2c-piece = {
> > piece-id = "i2c";
> > ...
> > };
> > misc-piece = {
> > piece-id = "misc";
> > ...
> > };
> > };
>
> I do like this approach; it's the kind of thing I proposed at:
>
> > http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg20414.html
Roughly, yes, though a little streamlined from the syntax suggested
there.
> One question though: Perhaps the base board has two instances of the
> same type of connector vendor,cape-socket, allowing 2 independent capes
> to be plugged in. When overlaying/grafting the child board's .dts, we'd
> need some way to specify the socket ID that was being plugged into. Is
> that the intent of the "id" property in your base board example above?
Yes, that's exactly what I had in mind for the "id" property.
Property names and other details entirely negotiable at this stage,
of course.
By the by, I think having multiple interchangable sockets could break
the convention based approach for avoiding collisions between phandles
I suggested, but another mail with some better thoughts on that
shortly to be posted.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote:
> On 11/12/2012 05:10 AM, Pantelis Antoniou wrote:
[snip]
> > Oh yes. In fact if one was to use a single kernel image for beagleboard
> > and beaglebone, for the cape to work for both, it is required for it's
> > dtb to be compatible.
>
> Well, as Grant pointed out, it's not actually strictly necessary for the
> .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb
> can be generated at run-time using dtc for example.
So, actually, I think a whole bunch of problems with phandle
resolution disappear if we don't try to define an overlay .dtb format,
or at least treat it only as a very shortlived object. A more precise
proposal below. Note that this works more or less equally well with
either the original overlay approach or the graft/graft-bundle
proposal I made elsewhere.
1) We annotate the base tree with some extra label information for
nodes which overlays are likely to want to reference by phandle. e.g.
beaglebone_pic: interrupt-controller@X {
...
phandle,symbolic-name = "beaglebone_pic";
};
We could extend dtc to (optionally?) auto-generate those properties
from its existing label syntax. Not sure if that's a good idea or
not yet. In any case, we compile this augmented base tree to .dtb as
normal and boot our kernel with it.
2) The information for the capes/modules/whatever is
distributed/packaged as .dts, never .dtb. When userspace detects the
new module (or the user explicitly tells it, if it's not probeable) it
picks up the correct dts and runs it through dtc in a special mode.
In this mode dtc takes the existing base tree (from /proc/device-tree,
say) as well as the new dts. In this mode, dtc allocates phandles for
the new tree fragment so as not to collide with anything from the
supplied base tree (as well as avoiding internal conflicts,
obviously). It also allows node references to the base tree by using
those label annotations from (1) to match symbolic names to the
phandle values in the base tree.
3) The resulting partial .dtb for the module is highly specific to the
base tree (which if the base tree was generated at runtime by firmware
could even be specific to a particular boot). But that's ok, because
we just spit it into the kernel, absolute phandle values and all, then
throw it away. Next time we need the module info, we recompile it
again.
> Of course, relying on .dts compatibility rather than .dtb compatibility
> might negatively impact the complexity of an initrd environment if we
> end up loading overlays from there...
Well, it does mean we'd need dtc in the initrd. But dtc has no
library dependencies except libc, so that really shouldn't be too
bad. In return we entirely avoid inventing a new phandle resolution
protocol.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
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 4/7] fs, notify: Add procfs fdinfo helper v4
On Mon, Nov 12, 2012 at 05:00:17PM -0800, Andrew Morton wrote:
> >
> > static const struct file_operations inotify_fops = {
> > +#ifdef CONFIG_PROC_FS
> > + .show_fdinfo= inotify_show_fdinfo,
> > +#endif
> > .poll = inotify_poll,
> > .read = inotify_read,
> > .fasync = inotify_fasync,
> > @@ -427,6 +428,9 @@ static long fanotify_ioctl(struct file *
> > }
> >
> > static const struct file_operations fanotify_fops = {
> > +#ifdef CONFIG_PROC_FS
> > + .show_fdinfo= fanotify_show_fdinfo,
> > +#endif
> > .poll = fanotify_poll,
> > .read = fanotify_read,
> > .write = fanotify_write,
>
> Then remove these ifdefs.
>
> That's if you can be bothered. It's a bit of a party trick which
> doesn't make things much clearer IMO.
Sure, i'll update.
--
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: manual merge of the arm-soc tree with the net-next tree
On 13 November 2012 05:15, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/net/ethernet/cadence/at91_ether.c between various commits from
> the net-next tree and commit bcd2360c1ff9 ("arm: at91: move platfarm_data
> to include/linux/platform_data/atmel.h") from the arm-soc tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/net/ethernet/cadence/at91_ether.c
> index e7a476c,35fc6edb..000
> --- a/drivers/net/ethernet/cadence/at91_ether.c
> +++ b/drivers/net/ethernet/cadence/at91_ether.c
> @@@ -25,53 -31,728 +25,54 @@@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
> + #include
The platform_data/atmel.h include shouldn't be necessary since the
driver already includes platform_data/macb.h.
Otherwise the fix up looks correct.
regards
Joachim Eastwood
--
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 v4 3/9] net: xfrm: use __this_cpu_read per-cpu helper
On Tue, Nov 13, 2012 at 09:52:09AM +0800, Shan Wei wrote:
> From: Shan Wei
>
Please add a proper commit message, explaining why you do this change.
>
> Signed-off-by: Shan Wei
> ---
> v4:
> derefrence pointer before reading to avoid compile warning.
> ---
> net/xfrm/xfrm_ipcomp.c |8 +++-
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/net/xfrm/xfrm_ipcomp.c b/net/xfrm/xfrm_ipcomp.c
> index e5246fb..2906d52 100644
> --- a/net/xfrm/xfrm_ipcomp.c
> +++ b/net/xfrm/xfrm_ipcomp.c
> @@ -276,18 +276,16 @@ static struct crypto_comp * __percpu
> *ipcomp_alloc_tfms(const char *alg_name)
> struct crypto_comp * __percpu *tfms;
> int cpu;
>
> - /* This can be any valid CPU ID so we don't need locking. */
> - cpu = raw_smp_processor_id();
>
> list_for_each_entry(pos, _tfms_list, list) {
> struct crypto_comp *tfm;
>
> - tfms = pos->tfms;
> - tfm = *per_cpu_ptr(tfms, cpu);
> + /* This can be any valid CPU ID so we don't need locking. */
> + tfm = __this_cpu_read(*pos->tfms);
This should just fetch the tfm pointer, so why exactly __this_cpu_read
is better than __this_cpu_ptr? Please keep in mind that performance is
not the most important thing here. It's much more important that it
works in any case.
--
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 3/7] fs, notify: Add file handle entry into inotify_inode_mark
On Mon, Nov 12, 2012 at 04:55:40PM -0800, Andrew Morton wrote:
> On Mon, 12 Nov 2012 14:14:43 +0400
> Cyrill Gorcunov wrote:
>
> > This file handle will be used in /proc/pid/fdinfo/fd
> > output, which in turn will allow to restore a watch
> > target after checkpoint (thus it's provided for
> > CONFIG_CHECKPOINT_RESTORE only).
>
> This changelog isn't very good.
>
> What appears to be happening is that you're borrowing exportfs's
> ability to encode file handles and this is being reused to transport
> inotify fd's to userspace for c/r? Or something else - I didn't try
> very hard. Please explain better?
Yes, we use fhandle mechanism to encode a watch target. This allows us
to remember fhandle on dump and open() it at restore time (ie when we do
restore a target we use open_by_handle_at syscall with fhandle).
I'll update the changelog and send it.
> > --- linux-2.6.git.orig/fs/notify/inotify/inotify.h
> > +++ linux-2.6.git/fs/notify/inotify/inotify.h
> > @@ -1,6 +1,7 @@
> > #include
> > #include
> > #include /* struct kmem_cache */
> > +#include
> >
> > extern struct kmem_cache *event_priv_cachep;
> >
> > @@ -9,9 +10,16 @@ struct inotify_event_private_data {
> > int wd;
> > };
> >
> > +#if defined(CONFIG_PROC_FS) && defined(CONFIG_EXPORTFS) &&
> > defined(CONFIG_CHECKPOINT_RESTORE)
> > +# define INOTIFY_USE_FHANDLE
> > +#endif
>
> Does this mean that c/r will fail to work properly if
> CONFIG_EXPORTFS=n? If so, that should be expressed in Kconfig
> dependencies?
Well, strictly speaking -- yes. We need exportfs to be compiled in.
But note the c/r will fail iif the task we're dumping does use
inotify. if there is no inotify usage -- then nothing will fail
even if exportfs is not compiled in. Also in our tool itself we
provide the "check" command which does verify if all features
we need are provided by the kernel. I'll think about adding
this config entry to deps. Thanks!
> > struct inotify_inode_mark {
> > struct fsnotify_mark fsn_mark;
> > int wd;
> > +#ifdef INOTIFY_USE_FHANDLE
> > + __u8 fhandle[sizeof(struct file_handle) + MAX_HANDLE_SZ];
> > +#endif
> > };
>
> Whoa. This adds 128+8 bytes to the inotify_inode_mark. That's a lot of
> bloat, and there can be a lot of inotify_inode_mark's in the system?
Yes, that's why it's not turned on by default, only if is c/r turned on.
iirc I've been said that usually only about 40 bytes is used (in the tests
I met only 8 bytes). Letme re-check all things.
> Also, what about alignment? That embedded `struct file_handle' will
> have a 4-byte alignment and if there's anything in there which is an
> 8-byte quantity then some architectures (ia64?) might get upset about
> the kernel-mode unaligned access. It appears that this won't happen in
> the present code, but are we future-proof?
>
> Why did you use a __u8, anyway? Could have done something like
>
> struct {
> struct file_handle fhandle;
> u8 pad[MAX_HANDLE_SZ];
> };
>
> and got some additional type safety and less typecasting?
Good point! Agreed on all. I'll update, thanks!
> > +#ifdef INOTIFY_USE_FHANDLE
> > +static int inotify_encode_wd_fhandle(struct inotify_inode_mark *mark,
> > struct dentry *dentry)
> > +{
> > + struct file_handle *fhandle = (struct file_handle *)mark->fhandle;
> > + int size, ret;
> > +
> > + BUILD_BUG_ON(sizeof(mark->fhandle) <= sizeof(struct file_handle));
> > +
> > + fhandle->handle_bytes = sizeof(mark->fhandle) - sizeof(struct
> > file_handle);
> > + size = fhandle->handle_bytes >> 2;
> > +
> > + ret = exportfs_encode_fh(dentry, (struct fid *)fhandle->f_handle,
> > , 0);
> > + if ((ret == 255) || (ret == -ENOSPC))
>
> Sigh. ENOSPC means "your disk is full". If this error ever gets back
> to userspace, our poor user will go and provision more disks and then
> wonder why that didn't fix anything.
Hmm, this errno is returned from exportfs_encode_fh. Letme think which one
is better here. I'll update. Thanks!
>
> > + return -EOVERFLOW;
>
> That doesn't seem very appropriate either, unsure.
Cyrill
--
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 1/2] drm: Add NVIDIA Tegra20 support
On 11/13/2012 05:55 AM, Thierry Reding wrote:
> This commit adds a KMS driver for the Tegra20 SoC. This includes basic
> support for host1x and the two display controllers found on the Tegra20
> SoC. Each display controller can drive a separate RGB/LVDS output.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - drop Linux-specific drm subdirectory for DT bindings documentation
> - remove display helper leftovers that belong in a later patch
> - reuse debugfs infrastructure provided by the DRM core
> - move vblank syncpoint defines to dc.h
> - use drm_compat_ioctl()
>
[...]
> diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
> new file mode 100644
> index 000..be1daf7
> --- /dev/null
> +++ b/drivers/gpu/drm/tegra/Kconfig
> @@ -0,0 +1,23 @@
> +config DRM_TEGRA
> + tristate "NVIDIA Tegra DRM"
> + depends on DRM && OF && ARCH_TEGRA
> + select DRM_KMS_HELPER
> + select DRM_GEM_CMA_HELPER
> + select DRM_KMS_CMA_HELPER
Just for curious, according to my testing, why the "CONFIG_CMA" is not
enabled while DRM_GEM_CMA_HELPER & DRM_KMS_CMA_HELPER are enabled here?
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + help
> + Choose this option if you have an NVIDIA Tegra SoC.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called tegra-drm.
> +
> +if DRM_TEGRA
> +
> +config DRM_TEGRA_DEBUG
> + bool "NVIDIA Tegra DRM debug support"
> + help
> + Say yes here to enable debugging support.
> +
> +endif
> diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
> new file mode 100644
> index 000..624a807
> --- /dev/null
> +++ b/drivers/gpu/drm/tegra/Makefile
> @@ -0,0 +1,7 @@
> +ccflags-y := -Iinclude/drm
> +ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG
> +
> +tegra-drm-y := drm.o fb.o dc.o host1x.o
> +tegra-drm-y += output.o rgb.o
> +
> +obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> new file mode 100644
> index 000..3f759a4
> --- /dev/null
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -0,0 +1,846 @@
> +/*
> + * Copyright (C) 2012 Avionic Design GmbH
> + * Copyright (C) 2012 NVIDIA CORPORATION. All rights reserved.
> + *
> + * 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 "drm.h"
> +#include "dc.h"
[...]
> +
> +static int tegra_dc_drm_exit(struct host1x_client *client)
> +{
> + struct tegra_dc *dc = host1x_client_to_dc(client);
> + int err;
> +
> + devm_free_irq(dc->dev, dc->irq, dc);
> +
> + if (IS_ENABLED(CONFIG_DEBUG_FS)) {
> + err = tegra_dc_debugfs_exit(dc);
> + if (err < 0)
> + dev_err(dc->dev, "debugfs cleanup failed: %d\n", err);
> + }
> +
> + err = tegra_dc_rgb_exit(dc);
> + if (err) {
> + dev_err(dc->dev, "failed to shutdown RGB output: %d\n", err);
> + return err;
> + }
> +
> + return 0;
> +}
> +
> +static const struct host1x_client_ops dc_client_ops = {
> + .drm_init = tegra_dc_drm_init,
> + .drm_exit = tegra_dc_drm_exit,
> +};
> +
> +static int tegra_dc_probe(struct platform_device *pdev)
> +{
> + struct host1x *host1x = dev_get_drvdata(pdev->dev.parent);
> + struct resource *regs;
> + struct tegra_dc *dc;
> + int err;
> +
> + dc = devm_kzalloc(>dev, sizeof(*dc), GFP_KERNEL);
> + if (!dc)
> + return -ENOMEM;
> +
> + INIT_LIST_HEAD(>list);
> + dc->dev = >dev;
> +
> + dc->clk = devm_clk_get(>dev, NULL);
> + if (IS_ERR_OR_NULL(dc->clk)) {
> + dev_err(>dev, "failed to get clock\n");
> + return -ENXIO;
> + }
> +
> + regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!regs) {
> + dev_err(>dev, "failed to get registers\n");
> + return -ENXIO;
> + }
> +
> + dc->regs = devm_request_and_ioremap(>dev, regs);
> + if (!dc->regs) {
> + dev_err(>dev, "failed to remap registers\n");
> + return -ENXIO;
> + }
> +
> + dc->irq = platform_get_irq(pdev, 0);
> + if (dc->irq < 0) {
> + dev_err(>dev, "failed to get IRQ\n");
> + return -ENXIO;
> + }
> +
> + INIT_LIST_HEAD(>client.list);
> + dc->client.ops = _client_ops;
> + dc->client.dev = >dev;
> +
> + err = host1x_register_client(host1x, >client);
> + if (err < 0) {
> + dev_err(>dev, "failed to register host1x client: %d\n",
> + err);
> + return err;
> + }
> +
> +
Re: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node objects
On Mon, Nov 12, 2012 at 10:03:56PM +0100, Rafael J. Wysocki wrote:
> > > +static acpi_status acpi_bus_add_resource(struct acpi_resource *res,
> > > + void *context)
> > > +{
> > > + struct list_head *list = context;
> > > + struct acpi_resource_list_entry *entry;
> > > +
> > > + entry = kzalloc(sizeof(*entry), GFP_KERNEL);
> > > + if (!entry)
> > > + return AE_NO_MEMORY;
> > > +
> > > + entry->resource = *res;
> >
> > This does not work well with all resource types - specifically those that
> > contain pointers, like acpi_resource_gpio and acpi_resource_source.
>
> Good point.
>
> Well, this pretty much means we can't copy those things.
Yeah. I only noticed this yesterday when I tested the GPIO translation in a
custom driver (since it uses the acpi_resource_gpio).
> > The memory for the resources gets freed once acpi_walk_resources() is done.
>
> I know that.
>
> Having to evaluate _CRS and creating a buffer, converting the output into
> ACPI resources and so on every time we need to look into the device's current
> resources is totally inefficient. We _need_ to cache the _CRS output.
I agree and besides having adev->resources is much easier to use than
calling acpi_walk_resources() everytime.
> Now, because of the pointers in certain types of resources, we can't
> make copies of the resource objects used by acpi_walk_resources() which
> makes that function totally unuseful to us.
>
> I suppose we can just do acpi_get_current_resources() and play with the
> buffer returned by it. That won't be nice, but still better than what we
> have.
I don't know any better option.
Thanks.
--
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/46] x86, mm: Split out split_mem_range from init_memory_mapping
On 2012年11月13日 14:20, Yinghai Lu wrote: On Mon, Nov 12, 2012 at 9:51 PM, Yasuaki Ishimatsu wrote: 2012/11/13 6:17, Yinghai Lu wrote: + nr_range = 0; This is unnecessary since it is set in the below. + nr_range = split_mem_range(mr, nr_range, start, end); Why not use 0 directly? nr_range = split_mem_range(mr, 0, start, end); -- 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-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/7] procfs: Add ability to plug in auxiliary fdinfo providers
On Mon, Nov 12, 2012 at 04:40:22PM -0800, Andrew Morton wrote: > > > > --- linux-2.6.git.orig/include/linux/fs.h > > +++ linux-2.6.git/include/linux/fs.h > > @@ -1517,6 +1517,8 @@ struct block_device_operations; > > #define HAVE_COMPAT_IOCTL 1 > > #define HAVE_UNLOCKED_IOCTL 1 > > > > +struct seq_file; > > + > > We already have a forward declaration of seq_file in fs.h. At line > 1583(!). > > This is why forward declarations should always be placed at the start > of the file, please. Yes, thanks a lot, Andrew! Cyrill -- 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 3/3] PM: Introduce Intel PowerClamp Driver
On Mon, 12 Nov 2012 22:33:36 -0800 Joe Perches wrote: > > Intel PowerClamp driver performs synchronized idle injection across > > all online CPUs. The goal is to maintain a given package level > > C-state ratio. > > style trivia: they are all good catches. will fix in the next version. -- Thanks, Jacob -- 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 2/2] regulator: tps80031: add regulator driver for tps80031
On Sun, Nov 11, 2012 at 08:42:01PM +0530, Laxman Dewangan wrote: > Add regulator driver for Texas Instrument TPS80031/TPS80032 device. > TPS80031/ TPS80032 Fully Integrated Power Management with Power > Path and Battery Charger. It has 5 configurable step-down > converters, 11 general purpose LDOs, VBUS generator and digital > output to control regulators. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] exec: do not leave bprm->interp on stack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kees Cook wrote: > On Tue, Nov 6, 2012 at 12:10 AM, P J P wrote: >> >> Hello Kees, Al, >> >> +-- On Sat, 27 Oct 2012, Kees Cook wrote --+ | If we change >> binfmt_script to not make a recursive call, then we still | need >> to keep the interp change somewhere off the stack. I still think >> | my patchset is the least bad. | | Al, do you have something >> else in mind? >> >> Guys, are there any updates further? >> >> Al, what's your take on the *rare* extra call to request_module? > > Without any other feedback, I'd like to use my minimal allocation > patch, since it fixes the problem and doesn't change any of the > semantics of how/when loading happens. As a first step, I think that we can go with the Keess' (nice/small/simple) patch. On the long run, exec should be reworked. Not only interp is modified, also credentials are set, e.g. when using "ping" as interpreter. With intransparent error handling and retry-logic, this might be a future local-root-exploit in the beginning (I tried to, but did not manage yet). Also a remark from Prasad Pandit did not make it to the list (or at least I missed the replies). > Yesterday, while testing Keess' patch I was reading through > execve(2) manual which says: path name must be a valid executable > which is NOT a script. > > $ man execve ... Interpreter scripts An interpreter script is a > text file that has execute permission enabled and whose first line > is of the form: > > #! interpreter [optional-arg] > > The interpreter must be a valid path name for an executable which > is not itself a script. Does someone know what POSIX says about that? I guess that interp recursion might have some usecases: Script uses interp, but interp was wrapped by admin or distribution folks into another script to fix something, e.g. to pass an additional arg. hd - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlCh7ZEACgkQxFmThv7tq+4X/QCeLN+0qUtP6Hhag1d4iwZ4PZbL evEAn2iPQH9mJ0zTHMs3qOsaWLRs9UWW =Ow3u -END PGP SIGNATURE- -- 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] boot_delay should only affect output
The boot_delay parameter affects all printk(), even if the log level
prevents visible output from the call. It results in delays greater
than the user intended without purpose.
This patch changes the behaviour of boot_delay to only delay output.
Signed-off-by: Andrew Cooks
---
kernel/printk.c | 40 +---
1 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index 66a2ea3..c098003 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -741,6 +741,21 @@ void __init setup_log_buf(int early)
free, (free * 100) / __LOG_BUF_LEN);
}
+static bool __read_mostly ignore_loglevel;
+
+static int __init ignore_loglevel_setup(char *str)
+{
+ ignore_loglevel = 1;
+ printk(KERN_INFO "debug: ignoring loglevel setting.\n");
+
+ return 0;
+}
+
+early_param("ignore_loglevel", ignore_loglevel_setup);
+module_param(ignore_loglevel, bool, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(ignore_loglevel, "ignore loglevel setting, to"
+ "print all kernel messages to the console.");
+
#ifdef CONFIG_BOOT_PRINTK_DELAY
static int boot_delay; /* msecs delay after each printk during bootup */
@@ -764,13 +779,15 @@ static int __init boot_delay_setup(char *str)
}
__setup("boot_delay=", boot_delay_setup);
-static void boot_delay_msec(void)
+static void boot_delay_msec(int level)
{
unsigned long long k;
unsigned long timeout;
- if (boot_delay == 0 || system_state != SYSTEM_BOOTING)
+ if ((boot_delay == 0 || system_state != SYSTEM_BOOTING)
+ || (level >= console_loglevel && !ignore_loglevel)) {
return;
+ }
k = (unsigned long long)loops_per_msec * boot_delay;
@@ -789,7 +806,7 @@ static void boot_delay_msec(void)
}
}
#else
-static inline void boot_delay_msec(void)
+static inline void boot_delay_msec(int level)
{
}
#endif
@@ -1232,21 +1249,6 @@ SYSCALL_DEFINE3(syslog, int, type, char __user *, buf,
int, len)
return do_syslog(type, buf, len, SYSLOG_FROM_CALL);
}
-static bool __read_mostly ignore_loglevel;
-
-static int __init ignore_loglevel_setup(char *str)
-{
- ignore_loglevel = 1;
- printk(KERN_INFO "debug: ignoring loglevel setting.\n");
-
- return 0;
-}
-
-early_param("ignore_loglevel", ignore_loglevel_setup);
-module_param(ignore_loglevel, bool, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(ignore_loglevel, "ignore loglevel setting, to"
- "print all kernel messages to the console.");
-
/*
* Call the console drivers, asking them to write out
* log_buf[start] to log_buf[end - 1].
@@ -1492,7 +1494,7 @@ asmlinkage int vprintk_emit(int facility, int level,
int this_cpu;
int printed_len = 0;
- boot_delay_msec();
+ boot_delay_msec(level);
printk_delay();
/* This stops the holder of console_sem just where we want him */
--
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: [GIT PULL REQUEST] UniCore32 update for v3.7-rc4
> -邮件原件- > 发件人: linus...@gmail.com [mailto:linus...@gmail.com] 代表 Linus Torvalds > 发送时间: 2012年11月11日 20:23 > 收件人: Guan > 抄送: Linux Kernel Mailing List > 主题: Re: [GIT PULL REQUEST] UniCore32 update for v3.7-rc4 > > Did you do the "request-pull" *after* you had done all the above? > > The ..BRANCH.NOT.VERIFIED.. implies that the request-pull couldn't > find the particular tag. I see. I've forgotten to push the new branch into the github. Thanks & Regards, Guan Xuetao > > Also, if you have an older version of git, you need to tell > request-pull explicitly that it is a tag, by saying "tags/for-linus" > rather than just "for-linus". Newer versions of git don't need that. > > Linus > > On Sun, Nov 11, 2012 at 1:06 PM, wrote: > >> On Fri, Nov 9, 2012 at 10:35 AM, guanxuetao > >> wrote: > >>> > >>> git://github.com/gxt/linux.git ..BRANCH.NOT.VERIFIED.. > >> > >> Let's try that again. With you checking what you send me. I hope > >> there's a signed tag somewhere, but the above certainly isn't that.. > >> > >> Linus > >> > > > > I used following command to generate a signed tag. > > 'git tag for-linus -s -u g...@mprc.pku.edu.cn' > > Then, I pushed this tag into github.com by: > > 'git push github -f --tags' > > Finally, I checked github repo, and tag 'for-linus' can be found. > > > > Could you tell me what's wrong with my operation? > > > > Thanks & Regards, > > Guan Xuetao -- 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] mm: cma: WARN if freed memory is still in use
Memory returned to free_contig_range() must have no other references. Let
kernel to complain loudly if page reference count is not equal to 1.
Signed-off-by: Marek Szyprowski
Reviewed-by: Kyungmin Park
CC: Michal Nazarewicz
---
mm/page_alloc.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 022e4ed..290c2eb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5888,8 +5888,13 @@ done:
void free_contig_range(unsigned long pfn, unsigned nr_pages)
{
- for (; nr_pages--; ++pfn)
- __free_page(pfn_to_page(pfn));
+ struct page *page = pfn_to_page(pfn);
+ int count = 0;
+ for (; nr_pages--; page++) {
+ count += page_count(page) != 1;
+ __free_page(page);
+ }
+ WARN(count != 0, "%d pages are still in use!\n", count);
}
#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/
Re: [PATCH] regulator: core: Update regulator_is_supported_voltage for fixed voltages
On Mon, Nov 12, 2012 at 10:13:55AM +0530, Tushar Behera wrote: > In that case, we should modify the test condition as following. > Currently it passes success when the regulator voltage is less than both > min_uV and max_uV. If ok, I will send another patch for this. Documentation/SubmittingPatches... signature.asc Description: Digital signature
Re: [PATCH v2 0/2] NVIDIA Tegra DRM driver
On Mon, Nov 12, 2012 at 05:17:18PM -0700, Stephen Warren wrote: > On 11/12/2012 02:55 PM, Thierry Reding wrote: > > This second version of this patch series addresses all the comments > > received so far. Most notably it takes advantage of the debugfs helpers > > provided by the DRM core. Oddly enough this actually increases the line > > count, but that's because the helpers don't fit with the subdevices > > approach as implemented by this driver. However some quick discussions > > with Rob Clark showed that Tegra DRM is not special in this respect but > > other drivers may need the same functionality. Eventually the debugfs > > code could be reworked on top of helpers that are better suited at the > > design of embedded, multi-device DRM drivers. > > > > Other than that there is some removal of code that was actually supposed > > to go into a later patch because it has dependencies that haven't been > > merged yet and some moving around of #defines and the device tree > > bindings documentation. Finally the driver now uses the DRM core's > > drm_compat_ioctl() instead of a custom and unimplemented (!) version. > > The series, > > Tested-by: Stephen Warren > > (on the Harmony board's HDMI output; I'll test other boards/outputs later). You also gave an Acked-by for the DT binding documentation in the first version of this patchset, does it apply to the rest of the patch as well? That is, can I add it to patch 1? Thierry pgpzQTcUfpIHn.pgp Description: PGP signature
[GIT PULL REQUEST] UniCore32 update for v3.7-rc4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The following changes since commit 0e4a43ed08e2f44aa7b96aa95d0a540d675483e1:
Linus Torvalds (1):
Merge git://git.kernel.org/.../steve/gfs2-3.0-fixes
are available in the git repository at:
git://github.com/gxt/linux.git unicore32
Al Viro (2):
unicore32: switch to generic kernel_thread()/kernel_execve()
unicore32: switch to generic sys_execve()
David Howells (1):
UAPI: (Scripted) Disintegrate arch/unicore32/include/asm
Guan Xuetao (4):
UniCore32 bugfix: add missed CONFIG_ZONE_DMA
UniCore32-bugfix: fix mismatch return value of __xchg_bad_pointer
UniCore32-bugfix: Remove definitions in asm/bug.h to solve difference
between native and cross compiler
unicore32: Use Kbuild infrastructure for kvm_para.h
Kautuk Consul (1):
unicore32/mm/fault.c: Port OOM changes to do_pf
Kees Cook (1):
arch/unicore32: remove CONFIG_EXPERIMENTAL
arch/unicore32/Kconfig |7 ++-
arch/unicore32/include/asm/Kbuild |1 -
arch/unicore32/include/asm/bug.h |5 -
arch/unicore32/include/asm/cmpxchg.h |2 +-
arch/unicore32/include/asm/kvm_para.h |1 -
arch/unicore32/include/asm/processor.h |5 -
arch/unicore32/include/asm/ptrace.h| 76 +
arch/unicore32/include/uapi/asm/Kbuild |7 ++
arch/unicore32/include/{ => uapi}/asm/byteorder.h |0
arch/unicore32/include/uapi/asm/ptrace.h | 90
arch/unicore32/include/{ => uapi}/asm/sigcontext.h |0
arch/unicore32/include/{ => uapi}/asm/unistd.h |1 +
arch/unicore32/kernel/entry.S | 20 ++---
arch/unicore32/kernel/process.c| 58 +++--
arch/unicore32/kernel/setup.h |6 ++
arch/unicore32/kernel/sys.c| 63 --
arch/unicore32/mm/fault.c | 37 ++--
17 files changed, 160 insertions(+), 219 deletions(-)
delete mode 100644 arch/unicore32/include/asm/kvm_para.h
rename arch/unicore32/include/{ => uapi}/asm/byteorder.h (100%)
create mode 100644 arch/unicore32/include/uapi/asm/ptrace.h
rename arch/unicore32/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/unicore32/include/{ => uapi}/asm/unistd.h (92%)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJQoeryAAoJENFylnOm3dTb0AUQAL0YxduSqFJHM7mvyTzfhedM
jw0nHoOvA+5N50t4uHmcqoto8R2VY5eTsho7rInKsURilFzwU7SNZBzHQ9cmHX5p
ljO5l5gxMMvTa3SYG0jRBhw1DgeVeHBpuPPfCEproJ5EOIFEFuDUvyUPKNcyEoRV
Ey3QZy4RTfe9DnKwBboqi80pN4Gl6E25VWGz3LnhaFzQXxUyZbm0kycuF1BGWu3F
TUubRs/OMYArNwq4LgZvcFs/7SrsJNSZ4f6wUnobYgJoBhe+Q5W3OS99JNb7PDuY
fxvJQJnbFfYlzk87U1slDTZk+Z7rMJ2sBfguBO13EOtc6DvZeaXMnaiW+HK6CSRW
dSpolVJ7CvCDXP2cFLn3ThMhM8gv0A/XnXnZ7h33zmXNC7HyZq6iMDoq4aqcClko
0LcJwypu1j5c0doQG/mVoiQje7un17pTY9yUNrgR4Ni4v9/Rq6NVy9ksckwEpS7i
g3QhdGtDPDD9zv/YLFId8GX+JbPC2QE2qVaEufj95YAD6AUJVgmqjZiRYKyw+RnY
cdMljswDa4iZC7/dOdOm5hR959Xtc2/XWAG735iWtb99VThgJzanim3pAZi1m+6z
Wp3Heil4IIcCXKdmIsjIeaVINYg00xQto+6+KTFYhtdRn/B6DUNS0+SmstrHVsld
eGUBUqfSFJiBLUIYeFbV
=MPI3
-END PGP SIGNATURE-
--
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] ARM: tegra: Add Tegra20 host1x support
On Tue, Nov 13, 2012 at 12:38:34PM +0800, Mark Zhang wrote:
> On 11/12/2012 05:39 PM, Mark Zhang wrote:
> > On 11/09/2012 09:20 PM, Thierry Reding wrote:
[...]
> >> @@ -1036,9 +1041,6 @@ static struct clk_duplicate tegra_clk_duplicates[] =
> >> {
> >> CLK_DUPLICATE("usbd", "utmip-pad",NULL),
> >> CLK_DUPLICATE("usbd", "tegra-ehci.0", NULL),
> >> CLK_DUPLICATE("usbd", "tegra-otg",NULL),
> >> - CLK_DUPLICATE("hdmi", "tegradc.0","hdmi"),
> >> - CLK_DUPLICATE("hdmi", "tegradc.1","hdmi"),
> >> - CLK_DUPLICATE("host1x", "tegra_grhost", "host1x"),
> >> CLK_DUPLICATE("2d", "tegra_grhost", "gr2d"),
> >> CLK_DUPLICATE("3d", "tegra_grhost", "gr3d"),
> >> CLK_DUPLICATE("epp","tegra_grhost", "epp"),
> >> @@ -1051,6 +1053,9 @@ static struct clk_duplicate tegra_clk_duplicates[] =
> >> {
> >> CLK_DUPLICATE("pll_p_out3", "tegra-i2c.1", "fast-clk"),
> >> CLK_DUPLICATE("pll_p_out3", "tegra-i2c.2", "fast-clk"),
> >> CLK_DUPLICATE("pll_p_out3", "tegra-i2c.3", "fast-clk"),
> >> + CLK_DUPLICATE("pll_p", "tegra-dc.0", "parent"),
> >> + CLK_DUPLICATE("pll_p", "tegra-dc.1", "parent"),
> >> + CLK_DUPLICATE("pll_d_out0", "tegra-hdmi", "parent"),
> >> };
>
> Why we need this "CLK_DUPLICATE"? Set the clock parent of the dc
> controllers to pll_p?
This was the method proposed by Stephen to abstract away the clock tree
differences between Tegra20 and Tegra30. The way this works is that we
can {devm_,}clk_get(>dev, "parent") in the display and HDMI
controllers' .probe() and it'll obtain the correct parent clock
independent of which version of Tegra is used.
Thierry
pgpR5fz3hGAI3.pgp
Description: PGP signature
Re: [rfc net-next v6 2/3] virtio_net: multiqueue support
On Mon, Nov 05, 2012 at 11:38:39AM +1030, Rusty Russell wrote:
> > @@ -924,11 +1032,10 @@ static void virtnet_get_ringparam(struct net_device
> > *dev,
> > {
> > struct virtnet_info *vi = netdev_priv(dev);
> >
> > - ring->rx_max_pending = virtqueue_get_vring_size(vi->rvq);
> > - ring->tx_max_pending = virtqueue_get_vring_size(vi->svq);
> > + ring->rx_max_pending = virtqueue_get_vring_size(vi->rq[0].vq);
> > + ring->tx_max_pending = virtqueue_get_vring_size(vi->sq[0].vq);
> > ring->rx_pending = ring->rx_max_pending;
> > ring->tx_pending = ring->tx_max_pending;
> > -
> > }
>
> This assumes all vqs are the same size. I think this should probably
> check: for mq mode, use the first vq, otherewise use the 0th.
For rx_pending/tx_pending I think what is required here is the
actual number of outstanding buffers.
Dave, Eric - right?
So this should be the total over all rings and to be useful,
rx_max_pending/tx_max_pending should be the total too.
> For bonus points, check this assertion at probe time.
Looks like we can easily support different queues too.
--
MST
--
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] pinctrl: imx: Fix the logic checking if not able to find pin reg map
On Tue, Nov 13, 2012 at 09:00:07AM +0800, Axel Lin wrote:
> Current code sets "pin_reg = >pin_regs[i];" in each loop iteration,
> so in the case of no-match, pin_reg is not NULL.
>
> Signed-off-by: Axel Lin
Thanks for the fix.
Acked-by: Dong Aisheng
Regards
Dong Aisheng
> ---
> drivers/pinctrl/pinctrl-imx.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/pinctrl-imx.c b/drivers/pinctrl/pinctrl-imx.c
> index f3d2384..525a2c8 100644
> --- a/drivers/pinctrl/pinctrl-imx.c
> +++ b/drivers/pinctrl/pinctrl-imx.c
> @@ -71,7 +71,7 @@ static const struct imx_pin_reg *imx_find_pin_reg(
> break;
> }
>
> - if (!pin_reg) {
> + if (i == info->npin_regs) {
> dev_err(info->dev, "Pin(%s): unable to find pin reg map\n",
> info->pins[pin].name);
> return NULL;
> --
> 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-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] RFC: pinctrl: grab default handler with bus notifiers
On Mon, Nov 12, 2012 at 01:21:40PM -0700, Stephen Warren wrote: > On 11/11/2012 05:22 AM, Linus Walleij wrote: > > Another solution that was discussed was whether to move > > the default pinctrl handle and state grab to the device > > core as an optional field in struct device itself, but > > I'd like to first propose this less intrusive mechanism. > I think doing that approach makes a lot more sense; wouldn't it > completely avoid the issues with deferred probe that this notifier-based > method can't solve? It would also be very much in line with e.g. > dev_get_regmap() - if every resource that a driver required were handled > like that, then deferred probe could be significantly isolated into the > driver core rather than in every driver... I have to say that I agree with this, notifiers seem to make life more complicated for limited gain. Otherwise I guess we could enhance notifiers so that they're able to trigger deferrals? signature.asc Description: Digital signature
Re: [PATCH 3/3] PM: Introduce Intel PowerClamp Driver
On Mon, 2012-11-12 at 14:03 -0800, Jacob Pan wrote:
> Intel PowerClamp driver performs synchronized idle injection across
> all online CPUs. The goal is to maintain a given package level C-state
> ratio.
style trivia:
[]
> diff --git a/drivers/thermal/intel_powerclamp.c
> b/drivers/thermal/intel_powerclamp.c
[]
> +
> +/* #define DEBUG */
> +
Adding this #define before any #include
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +#include
> +#include
[]
> +static int window_size_set(const char *arg, const struct kernel_param *kp)
> +{
[]
> + if (new_window_size >= 10 || new_window_size < 2) {
> + pr_err("PowerClamp: invalid window size %lu, between 2-10\n",
> + new_window_size);
Means there's no need for "PowerClamp: " prefixes with pr_fmt
pr_err("invalid window size %lu...
and all the other pr_ uses get prefixed too.
> +static u64 pkg_state_counter(void)
> +{
> + u64 val;
> + u64 count = 0;
> +
> + static int skip_c2;
> + static int skip_c3;
> + static int skip_c6;
> + static int skip_c7;
bool?
--
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/46] x86, mm: Split out split_mem_range from init_memory_mapping
On Mon, Nov 12, 2012 at 9:51 PM, Yasuaki Ishimatsu wrote: > 2012/11/13 6:17, Yinghai Lu wrote: >> + nr_range = 0; > > This is unnecessary since it is set in the below. > >> + nr_range = split_mem_range(mr, nr_range, start, end); -- 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] x86/nmi: export local_touch_nmi() symbol for modules
Signed-off-by: Jacob Pan
---
arch/x86/kernel/nmi.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index f84f5c5..6030805 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -509,3 +509,4 @@ void local_touch_nmi(void)
{
__this_cpu_write(last_nmi_rip, 0);
}
+EXPORT_SYMBOL_GPL(local_touch_nmi);
--
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/
[PATCH 0/3] pm: Intel powerclamp driver
Hi, We have done some experiment with idle injection on Intel platforms. The idea is to use the increasingly power efficient package level C-states for power capping and passive thermal control. Documentation is included in the patch to explain the theory of operation, performance implication, calibration, scalability, and user interface. Please refer to the following file for more details. Documentation/thermal/intel_powerclamp.txt Arjan van de Ven created the original idea and driver, I have been refining driver in hope that they can be to be useful beyond a proof of concept. Jacob Pan (3): tick: export nohz tick idle symbols for module use x86/nmi: export local_touch_nmi() symbol for modules PM: Introduce Intel PowerClamp Driver Documentation/thermal/intel_powerclamp.txt | 307 +++ arch/x86/kernel/nmi.c |1 + drivers/thermal/Kconfig| 10 + drivers/thermal/Makefile |1 + drivers/thermal/intel_powerclamp.c | 766 kernel/time/tick-sched.c |2 + 6 files changed, 1087 insertions(+) create mode 100644 Documentation/thermal/intel_powerclamp.txt create mode 100644 drivers/thermal/intel_powerclamp.c -- 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/
[PATCH 3/3] PM: Introduce Intel PowerClamp Driver
Intel PowerClamp driver performs synchronized idle injection across all online CPUs. The goal is to maintain a given package level C-state ratio. Compared to other throttling methods already exist in the kernel, such as ACPI PAD (taking CPUs offline) and clock modulation, this is often more efficient in terms of performance per watt. Please refer to Documentation/thermal/intel_powerclamp.txt for more details. Signed-off-by: Arjan van de Ven Signed-off-by: Jacob Pan --- Documentation/thermal/intel_powerclamp.txt | 307 +++ drivers/thermal/Kconfig| 10 + drivers/thermal/Makefile |1 + drivers/thermal/intel_powerclamp.c | 766 4 files changed, 1084 insertions(+) create mode 100644 Documentation/thermal/intel_powerclamp.txt create mode 100644 drivers/thermal/intel_powerclamp.c diff --git a/Documentation/thermal/intel_powerclamp.txt b/Documentation/thermal/intel_powerclamp.txt new file mode 100644 index 000..332de4a --- /dev/null +++ b/Documentation/thermal/intel_powerclamp.txt @@ -0,0 +1,307 @@ +=== +INTEL POWERCLAMP DRIVER +=== +By: Arjan van de Ven +Jacob Pan + +Contents: + (*) Introduction + - Goals and Objectives + + (*) Theory of Operation + - Idle Injection + - Calibration + + (*) Performance Analysis + - Effectiveness and Limitations + - Power vs Performance + - Scalability + - Calibration + - Comparison with Alternative Techniques + + (*) Usage and Interfaces + - Generic Thermal Layer (sysfs) + - Kernel APIs (TBD) + + +INTRODUCTION + + +Consider the situation where a system’s power consumption must be +reduced at runtime, due to power budget, thermal constraint, or noise +level, and where active cooling is not preferred. Software managed +passive power reduction must be performed to prevent the hardware +actions that are designed for catastrophic scenarios. + +Currently, P-states, T-states (clock modulation), and CPU offlining +are used for CPU throttling. + +On Intel CPUs, C-states provide effective power reduction, but so far +they’re only used opportunistically, based on workload. With the +development of intel_powerclamp driver, the method of synchronizing +idle injection across all online CPU threads was introduced. The goal +is to achieve forced and controllable C-state residency. + +Test/Analysis has been made in the areas of power, performance, +scalability, and user experience. In many cases, clear advantage is +shown over taking the CPU offline or modulating the CPU clock. + + +=== +THEORY OF OPERATION +=== + +Idle Injection +-- + +On modern Intel processors (Nehalem or later), package level C-state +residency is available in MSRs, thus also available to the kernel. + +These MSRs are: + #define MSR_PKG_C2_RESIDENCY 0x60D + #define MSR_PKG_C3_RESIDENCY 0x3F8 + #define MSR_PKG_C6_RESIDENCY 0x3F9 + #define MSR_PKG_C7_RESIDENCY 0x3FA + +If the kernel can also inject idle time to the system, then a +closed-loop control system can be established that manages package +level C-state. The intel_powerclamp driver is conceived as such a +control system, where the target set point is a user-selected idle +ratio (based on power reduction), and the error is the difference +between the actual package level C-state residency ratio and the target idle +ratio. + +Injection is controlled by high priority kernel threads, spawned for +each online CPU. + +These kernel threads, with SCHED_FIFO class, are created to perform +clamping actions of controlled duty ratio and duration. Each per-CPU +thread synchronizes its idle time and duration, based on the rounding +of jiffies, so accumulated errors can be prevented to avoid a jittery +effect. Threads are also bound to the CPU such that they cannot be +migrated, unless the CPU is taken offline. In this case, threads +belong to the offlined CPUs will be terminated immediately. + +Running as SCHED_FIFO and relatively high priority, also allows such +scheme to work for both preemptable and non-preemptable kernels. +Alignment of idle time around jiffies ensures scalability for HZ +values. This effect can be better visualized using a Perf timechart. +The following diagram shows the behavior of kernel thread +kidle_inject/cpu. During idle injection, it runs monitor/mwait idle +for a given "duration", then relinquishes the CPU to other tasks, +until the next time interval. + +The NOHZ schedule tick is disabled during idle time, but interrupts +are not masked. Tests show that the extra wakeups from scheduler tick +have a dramatic impact on the effectiveness of the powerclamp driver +on large scale systems (Westmere system with 80
[PATCH 1/3] tick: export nohz tick idle symbols for module use
Allow drivers such as intel_powerclamp to use these apis for
turning on/off ticks during idle.
Signed-off-by: Jacob Pan
---
kernel/time/tick-sched.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index a402608..7c38f08 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -510,6 +510,7 @@ void tick_nohz_idle_enter(void)
local_irq_enable();
}
+EXPORT_SYMBOL_GPL(tick_nohz_idle_enter);
/**
* tick_nohz_irq_exit - update next tick event from interrupt exit
@@ -634,6 +635,7 @@ void tick_nohz_idle_exit(void)
local_irq_enable();
}
+EXPORT_SYMBOL_GPL(tick_nohz_idle_exit);
static int tick_nohz_reprogram(struct tick_sched *ts, ktime_t now)
{
--
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/
linux-next: Tree for Nov 13
Hi all, News: next-20121115 will be the last release until next-20121126 (which should be just be after -rc7, I guess - assuming that Linus does not release v3.7 before then), so if you want something in linux-next for a reasonable amount of testing, it should probably be committed in the next day or so. Changes since 20121112: New tree: ftrace The v4l-dvb tree still had its build failure so I used the version from next-20121026. The usb tree gained a conflict against usb.current tree. The staging tree gained a conflict against the mfd tree and a build failure for which I reverted a commit. The arm-soc tree gained conflicts against the usb, net-next and pinctrl trees. The akpm tree still had its build failures for which I have reverted a few patches. 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 210 trees (counting Linus' and 28 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 (77b6706 Linux 3.7-rc5) Merging fixes/master (12250d8 Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux) Merging kbuild-current/rc-fixes (bad9955 menuconfig: Replace CIRCLEQ by list_head-style lists.) Merging arm-current/fixes (6404f0b ARM: 7569/1: mm: uninitialized warning corrections) Merging m68k-current/for-linus (8a745ee m68k: Wire up kcmp) Merging powerpc-merge/merge (8c23f40 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging sparc/master (b251f0f Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging net/master (0c9f79b ipv4: avoid undefined behavior in do_ip_setsockopt()) Merging sound-current/for-linus (0519363 ALSA: hda - Add a missing quirk entry for iMac 9,1) Merging pci-current/for-linus (ff8e59b PCI/portdrv: Don't create hotplug slots unless port supports hotplug) Merging wireless/master (6fe7cc7 ath9k: Test for TID only in BlockAcks while checking tx status) Merging driver-core.current/driver-core-linus (8f0d816 Linux 3.7-rc3) Merging tty.current/tty-linus (8f0d816 Linux 3.7-rc3) Merging usb.current/usb-linus (d99e65b USB: fix build with XEN and EARLY_PRINTK_DBGP enabled but USB_SUPPORT disabled) Merging staging.current/staging-linus (77b6706 Linux 3.7-rc5) Merging char-misc.current/char-misc-linus (8f0d816 Linux 3.7-rc3) Merging input-current/for-linus (40a8120 Input: MT - document new 'flags' argument of input_mt_init_slots()) Merging md-current/for-linus (ed30be0 MD RAID10: Fix oops when creating RAID10 arrays via dm-raid.c) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (9efade1 crypto: cryptd - disable softirqs in cryptd_queue_worker to prevent data corruption) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) 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 of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of
Re: [PATCH] mfd: arizona: Move chip reset to before register patch
On Mon, Nov 12, 2012 at 05:56:48PM +, Charles Keepax wrote: > In the absence of a physical reset line the chip is reset by writing the > first register, this was done after the register patch was applied which > negates the settings applied in the register patch. > > This patch moves the reset to take place before the register patch is > applied. No, we should never write to the chip until we have successfully identified it. Do a sync or similar instead (we should be triggering this very soon afterwards via runtime PM anyway). signature.asc Description: Digital signature
Re: [PATCH 02/46] x86, mm: Split out split_mem_range from init_memory_mapping
2012/11/13 6:17, Yinghai Lu wrote:
> So make init_memory_mapping smaller and readable.
>
> Suggested-by: Ingo Molnar
> Signed-off-by: Yinghai Lu
> Reviewed-by: Pekka Enberg
> ---
> arch/x86/mm/init.c | 42 ++
> 1 files changed, 26 insertions(+), 16 deletions(-)
>
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index aa5b0da..6d8e102 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -146,25 +146,13 @@ static int __meminit save_mr(struct map_range *mr, int
> nr_range,
> return nr_range;
> }
>
> -/*
> - * Setup the direct mapping of the physical memory at PAGE_OFFSET.
> - * This runs before bootmem is initialized and gets pages directly from
> - * the physical memory. To access them they are temporarily mapped.
> - */
> -unsigned long __init_refok init_memory_mapping(unsigned long start,
> -unsigned long end)
> +static int __meminit split_mem_range(struct map_range *mr, int nr_range,
> + unsigned long start,
> + unsigned long end)
> {
> unsigned long start_pfn, end_pfn;
> - unsigned long ret = 0;
> unsigned long pos;
> - struct map_range mr[NR_RANGE_MR];
> - int nr_range, i;
> -
> - printk(KERN_INFO "init_memory_mapping: [mem %#010lx-%#010lx]\n",
> -start, end - 1);
> -
> - memset(mr, 0, sizeof(mr));
> - nr_range = 0;
> + int i;
>
> /* head if not big page alignment ? */
> start_pfn = start >> PAGE_SHIFT;
> @@ -258,6 +246,28 @@ unsigned long __init_refok init_memory_mapping(unsigned
> long start,
> (mr[i].page_size_mask & (1<(mr[i].page_size_mask & (1<
> + return nr_range;
> +}
> +
> +/*
> + * Setup the direct mapping of the physical memory at PAGE_OFFSET.
> + * This runs before bootmem is initialized and gets pages directly from
> + * the physical memory. To access them they are temporarily mapped.
> + */
> +unsigned long __init_refok init_memory_mapping(unsigned long start,
> +unsigned long end)
> +{
> + struct map_range mr[NR_RANGE_MR];
> + unsigned long ret = 0;
> + int nr_range, i;
> +
> + pr_info("init_memory_mapping: [mem %#010lx-%#010lx]\n",
> +start, end - 1);
> +
> + memset(mr, 0, sizeof(mr));
> + nr_range = 0;
This is unnecessary since it is set in the below.
> + nr_range = split_mem_range(mr, nr_range, start, end);
Thanks,
Yasuaki Ishimatsu
> +
> /*
>* Find space for the kernel direct mapping tables.
>*
>
--
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 final tree (staging tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
In file included from drivers/power/lp8788-charger.c:15:0:
include/linux/iio/consumer.h:76:21: error: unknown type name 'u8'
include/linux/iio/consumer.h:78:11: error: expected ';', ',' or ')' before
'void'
Caused by commit 92d1079b281f ("staging:iio: add a callback buffer for in
kernel push interface"). Presumably just a missing include.
I have reverted that commit for today (it introduces a set of not yet
used interfaces).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpIcNbI47Rag.pgp
Description: PGP signature
RE: [PATCH 1/1] mm: Export a function to read vm_committed_as
> -Original Message- > From: David Rientjes [mailto:rient...@google.com] > Sent: Monday, November 12, 2012 6:49 PM > To: Dan Magenheimer > Cc: KY Srinivasan; Konrad Wilk; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; a...@firstfloor.org; a...@linux-foundation.org; linux- > m...@kvack.org; kamezawa.hiroy...@gmail.com; mho...@suse.cz; > han...@cmpxchg.org; ying...@google.com > Subject: RE: [PATCH 1/1] mm: Export a function to read vm_committed_as > > On Mon, 12 Nov 2012, Dan Magenheimer wrote: > > > > > Why? Is xen using it for a different inference? > > > > > > I think it is good to separate these patches. Dan (copied here) wrote the > > > code > for the > > > Xen self balloon driver. If it is ok with him I can submit the patch for > > > Xen as > well. > > > > Hi KY -- > > > > If I understand correctly, this would be only a cosmetic (function renaming) > change > > to the Xen selfballooning code. If so, then I will be happy to Ack when I > > see the patch. However, Konrad (konrad.w...@oracle.com) is the maintainer > > for all Xen code so you should ask him... and (from previous painful > > experience) > > it can be difficult to sync even very simple interdependent changes going > through > > different maintainers without breaking linux-next. So I can't offer any > > help with that process, only commiseration. :-( > > > > I think this should be done in the same patch as the function getting > introduced with a cc to Konrad and routed through -mm; even better, > perhaps he'll have some useful comments for how this is used for xen that > can be included for context. > Ok; I will send out a single patch. I am hoping this can be applied soon as Hyper-V balloon driver is queued behind this. Regards, K. Y -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/12/2012 06:05 PM, David Gibson wrote:
> On Fri, Nov 09, 2012 at 09:42:37PM +, Grant Likely wrote:
...
> 2) graft bundle
>
> The base tree has something like this:
>
> ...
> i2c@XXX {
> ...
> cape-socket {
> compatible = "vendor,cape-socket";
> id = "Socket-A";
> piece-id = "i2c";
> ranges = < ... >;
> };
> };
> ...
> spi@YYY {
> ...
> cape-socket {
> compatible = "vendor,cape-socket";
> id = "Socket-A";
> piece-id = "spi";
> ranges = < ... >;
> };
> };
> ...
> cape-socket {
> compatible = "vendor,cape-socket";
> id = "Socket-A";
> piece-id = "misc";
> interrupt-map = < ... >;
> interrupt-map-mask = < ... >;
> gpio-map = < ... >;
> gpio-map-mask = < ... >;
> };
>
> Then instead of grafting a single subtree for the socket, we install a
> "bundle" of subtrees, one each for each of the pieces within the
> socket. That bundle could either be an actual set of multiple fdts,
> or they could be placed into one fdt with a dummy root node, something like:
>
> / {
> plugin-bundle;
> compatible = "vendor,cape-plugin";
> version = ...;
> i2c-piece = {
> piece-id = "i2c";
> ...
> };
> misc-piece = {
> piece-id = "misc";
> ...
> };
> };
I do like this approach; it's the kind of thing I proposed at:
> http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg20414.html
One question though: Perhaps the base board has two instances of the
same type of connector vendor,cape-socket, allowing 2 independent capes
to be plugged in. When overlaying/grafting the child board's .dts, we'd
need some way to specify the socket ID that was being plugged into. Is
that the intent of the "id" property in your base board example above?
--
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] mm: Export a function to read vm_committed_as
> -Original Message- > From: Dan Magenheimer [mailto:dan.magenhei...@oracle.com] > Sent: Monday, November 12, 2012 6:32 PM > To: KY Srinivasan; David Rientjes; Konrad Wilk > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > a...@firstfloor.org; a...@linux-foundation.org; linux...@kvack.org; > kamezawa.hiroy...@gmail.com; mho...@suse.cz; han...@cmpxchg.org; > ying...@google.com > Subject: RE: [PATCH 1/1] mm: Export a function to read vm_committed_as > > > From: KY Srinivasan [mailto:k...@microsoft.com] > > Sent: Monday, November 12, 2012 3:58 PM > > To: David Rientjes > > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; > > o...@aepfle.de; a...@canonical.com; a...@firstfloor.org; akpm@linux- > foundation.org; linux...@kvack.org; > > kamezawa.hiroy...@gmail.com; mho...@suse.cz; han...@cmpxchg.org; > ying...@google.com; Dan Magenheimer > > Subject: RE: [PATCH 1/1] mm: Export a function to read vm_committed_as > > > > > -Original Message- > > > From: David Rientjes [mailto:rient...@google.com] > > > Sent: Monday, November 12, 2012 4:54 PM > > > To: KY Srinivasan > > > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > > > a...@firstfloor.org; a...@linux-foundation.org; linux...@kvack.org; > > > kamezawa.hiroy...@gmail.com; mho...@suse.cz; han...@cmpxchg.org; > > > ying...@google.com > > > Subject: RE: [PATCH 1/1] mm: Export a function to read vm_committed_as > > > > > > On Sun, 11 Nov 2012, KY Srinivasan wrote: > > > > > > > Thanks for the prompt response. For the Linux balloon driver for > > > > Hyper-V, I > > > need access > > > > to the metric that reflects the system wide memory commitment made by > the > > > guest kernel. > > > > In the Hyper-V case, this information is one of the many metrics used to > drive > > > the policy engine > > > > on the host. Granted, the interface name I have chosen here could be > > > > more > > > generic; how about > > > > read_mem_commit_info(void). I am open to suggestions here. > > > > > > > > > > I would suggest vm_memory_committed() and there shouldn't be a > comment > > > describing that this is just a wrapper for modules to read > > > vm_committed_as, that's apparent from the implementation: it should be > > > describing exactly what this value represents and why it is a useful > > > metric (at least in the case that you're concerned about). > > > > Will do; thanks. > > > > > > > With regards to making changes to the Xen self ballooning code, I would > > > > like > to > > > separate that patch > > > > from the patch that implements the exported mechanism to access the > > > memory commitment information. > > > > > > Why? Is xen using it for a different inference? > > > > I think it is good to separate these patches. Dan (copied here) wrote the > > code > for the > > Xen self balloon driver. If it is ok with him I can submit the patch for > > Xen as well. > > Hi KY -- > > If I understand correctly, this would be only a cosmetic (function renaming) > change > to the Xen selfballooning code. If so, then I will be happy to Ack when I > see the patch. However, Konrad (konrad.w...@oracle.com) is the maintainer > for all Xen code so you should ask him... and (from previous painful > experience) > it can be difficult to sync even very simple interdependent changes going > through > different maintainers without breaking linux-next. So I can't offer any > help with that process, only commiseration. :-( > > Dan > Dan, Thank you. I will send the patches out soon. Regards, K. Y -- 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] MIPS: BCM63XX: enable serial through Device Tree
On 11/11/2012 05:50 AM, Jonas Gorski wrote:
> Enable serial through Device Tree board files instead of legacy
> board files.
> diff --git a/arch/mips/bcm63xx/dts/96328avng.dts
> b/arch/mips/bcm63xx/dts/96328avng.dts
> ubus@1000 {
>
> + serial@100 {
Very minor nit: Why the blank line there?
> + status = "ok";
> + };
> };
> };
--
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] MIPS: BCM63XX: add empty Device Trees for all supported boards
On 11/11/2012 05:50 AM, Jonas Gorski wrote:
> Add empty board files for all boards supported by the legacy board
> support.
> diff --git a/arch/mips/bcm63xx/dts/96328avng.dts
> b/arch/mips/bcm63xx/dts/96328avng.dts
> +/ {
> + model = "96328avng";
> + compatible = "96328avng";
The board should be compatible with both the board name and the SoC on
the board. I know that right now the MIPS code is choosing the DT to use
based on the board name, but I think it's more typical to pass an
explicit DT to the kernel, and then choose the kernel support to execute
based on the compatible value (certainly this is the case on ARM and I
assume other architectures too). That would require the DT content to
include the SoC name in the compatible property, so that the kernel
support didn't then need to contain a table of all supported board names.
> + ubus@1000 {
> +
> + };
Do you need to include this empty node in each file? I guess it gets
added to in the next patch so it's not a big deal though.
> diff --git a/arch/mips/bcm63xx/dts/Kconfig b/arch/mips/bcm63xx/dts/Kconfig
> +config BOARD_96328AVNG
> + bool "96328avng reference board"
> + select BCM63XX_CPU_6328
Why not simply compile all DTs whenever the SoC support is enabled? I
suppose you're trying to avoid packing all the DTs into the kernel
image. Does it make more sense to amend the MIPS kernel boot process so
that a single user-/firmware-selected DT is passed to the kernel, rather
than packing the DTs into the kernel and selecting 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: [BUGFIX] PM: Fix active child counting when disabled and forbidden
On Mon, 2012-11-12 at 21:32 -0500, Alan Stern wrote: > On Tue, 13 Nov 2012, Huang Ying wrote: > > > Sorry, my original idea is: > > > > pm_runtime_disable will put device into SUSPENDED state if > > dev->power.runtime_auto is clear. pm_runtime_allow will put > > device into SUSPENDED state if dev->power.disable_depth > 0. > > That's close to what I suggested. > > > So in general, my original idea is to manage device runtime power state > > automatically instead of manually, especially when device is in disabled > > state. > > > > disabled + forbidden-> ACTIVE > > disabled + !forbidden -> SUSPENDED > > This is not quite right. Consider a device that is in runtime suspend > when a system sleep starts. When the system sleep ends, the device > will be resumed but the PM core will still think its state is > SUSPENDED. The subsystem has to tell the PM core that the device is > now ACTIVE. Currently, subsystems do this by calling > pm_runtime_disable, pm_runtime_set_active, pm_runtime_enable. Under > your scheme this wouldn't work; the pm_runtime_set_active call would > fail because the device was !forbidden. Thanks for your information. For this specific situation, is it possible to call pm_runtime_resume() or pm_request_resume() for the device? > > enabled + forbidden -> ACTIVE > > enabled + !forbidden-> auto > > > > Why we can not do that? > > See above. What we can do instead is: > > disabled + forbidden-> ACTIVE > disabled + !forbidden -> anything > > which is basically what I proposed. > > > > This means: > > > > > > pm_runtime_set_suspended should fail if dev->power.runtime_auto > > > is clear. > > > > I think we can WARN_ON() here. Because the caller should responsible > > for state consistence if they decide to manage runtime power state > > manually. > > No. Drivers should not have to worry about whether runtime PM is > forbidden. Worrying about that is the PM core's job. En... It appears that what caller can do is just do not call pm_runtime_set_suspended() if forbidden. So your method should be better. > > > pm_runtime_forbid should call pm_runtime_set_active if > > > dev->power.disable_depth > 0. (This would run into a problem > > > if the parent is suspended and disabled. Maybe > > > pm_runtime_forbid should fail when this happens.) > > > > pm_runtime_forbid() may be called via echo "on" > .../power/control. I > > think it is hard to refuse the request from user space to forbid runtime > > PM. Device can always work with full power. > > It can't if the parent is in SUSPEND. If necessary, the user can write > "on" to the parent's power/control attribute first. Is it possible to call pm_runtime_set_active() for the parent if the parent is disabled and SUSPENDED. > > > Finally, we probably should make a third change even though it isn't > > > strictly necessary: > > > > > > pm_runtime_allow should call pm_runtime_set_suspended if > > > dev->power.disable_depth > 0. > > > > I think this is something similar to manage device power state > > automatically if disabled. > > Yes, it is similar but not exactly the same as your proposal. It appears that there is race condition between this and the pm_runtime_disable, pm_runtime_set_active, pm_runtime_enable sequence you mentioned ealier. thread 1thread 2 pm_runtime_disable pm_runtime_set_active pm_runtime_allow pm_runtime_set_suspended pm_runtime_enable Best Regards, Huang Ying -- 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/3] ARM: tegra: dt: Add entry for tegra20 sflash controller.
This patch series add the dt entry for tegra20 sflash controller, add AUXDATA in board dt file for driver name and enable in tegra_defconfig. Laxman Dewangan (3): ARM: tegra: dts: add sflash controller dt entry ARM: tegra: Add OF_DEV_AUXDATA for sflash driver in board dt ARM: config: tegra: enable SFLASH controller driver arch/arm/boot/dts/tegra20.dtsi | 10 ++ arch/arm/configs/tegra_defconfig |1 + arch/arm/mach-tegra/board-dt-tegra20.c |2 ++ 3 files changed, 13 insertions(+), 0 deletions(-) -- 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/3] ARM: config: tegra: enable SFLASH controller driver
Signed-off-by: Laxman Dewangan --- arch/arm/configs/tegra_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig index 9dac09b..39107b1 100644 --- a/arch/arm/configs/tegra_defconfig +++ b/arch/arm/configs/tegra_defconfig @@ -120,6 +120,7 @@ CONFIG_I2C_MUX=y CONFIG_I2C_MUX_PINCTRL=y CONFIG_I2C_TEGRA=y CONFIG_SPI=y +CONFIG_SPI_TEGRA20_SFLASH=y CONFIG_SPI_TEGRA20_SLINK=y CONFIG_GPIO_PCA953X_IRQ=y CONFIG_GPIO_TPS6586X=y -- 1.7.1.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] ARM: tegra: Add OF_DEV_AUXDATA for sflash driver in board dt
Add OF_DEV_AUXDATA for sflash controller driver for Tegra20
board dt files.
Set the parent clock of sflash controller to PLLP and configure
clock to 20MHz.
Signed-off-by: Laxman Dewangan
---
arch/arm/mach-tegra/board-dt-tegra20.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
b/arch/arm/mach-tegra/board-dt-tegra20.c
index 22f5a9b..1198e84 100644
--- a/arch/arm/mach-tegra/board-dt-tegra20.c
+++ b/arch/arm/mach-tegra/board-dt-tegra20.c
@@ -89,6 +89,7 @@ struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
_ehci3_pdata),
OF_DEV_AUXDATA("nvidia,tegra20-apbdma", TEGRA_APB_DMA_BASE,
"tegra-apbdma", NULL),
OF_DEV_AUXDATA("nvidia,tegra20-pwm", TEGRA_PWFM_BASE, "tegra-pwm",
NULL),
+ OF_DEV_AUXDATA("nvidia,tegra20-sflash", 0x7000c380, "spi", NULL),
OF_DEV_AUXDATA("nvidia,tegra20-slink", 0x7000D400, "spi_tegra.0", NULL),
OF_DEV_AUXDATA("nvidia,tegra20-slink", 0x7000D600, "spi_tegra.1", NULL),
OF_DEV_AUXDATA("nvidia,tegra20-slink", 0x7000D800, "spi_tegra.2", NULL),
@@ -112,6 +113,7 @@ static __initdata struct tegra_clk_init_table
tegra_dt_clk_init_table[] = {
{ "sdmmc1", "pll_p",4800, false},
{ "sdmmc3", "pll_p",4800, false},
{ "sdmmc4", "pll_p",4800, false},
+ { "spi","pll_p",2000, false },
{ "sbc1", "pll_p",1, false },
{ "sbc2", "pll_p",1, false },
{ "sbc3", "pll_p",1, false },
--
1.7.1.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] ARM: tegra: dts: add sflash controller dt entry
Nvidia's Tegra20 have the SPI (SFLASH) controller to
interface with spi flash device which is used for system
boot. Add DT entry for this controller.
Signed-off-by: Laxman Dewangan
---
arch/arm/boot/dts/tegra20.dtsi | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 71a650d..32cb09d 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -195,6 +195,16 @@
status = "disabled";
};
+ spi@7000c380 {
+ compatible = "nvidia,tegra20-sflash";
+ reg = <0x7000c380 0x80>;
+ interrupts = <0 39 0x04>;
+ nvidia,dma-request-selector = < 11>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
spi@7000d400 {
compatible = "nvidia,tegra20-slink";
reg = <0x7000d400 0x200>;
--
1.7.1.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] MIPS: BCM63XX: register GPIO controller through Device Tree
On 11/11/2012 05:50 AM, Jonas Gorski wrote: > Register the GPIO controller through Device Tree and add the > appropriate values in the include files. > > Since we can't register a platform driver at this early stage move the > direct call to bcm63xx_gpio_init from prom_init to an arch initcall. > diff --git a/Documentation/devicetree/bindings/gpio/bcm63xx-gpio.txt > b/Documentation/devicetree/bindings/gpio/bcm63xx-gpio.txt > +- #gpio-cells: Must be <2>. The first cell is the GPIO pin, and > + the second one the standard linux flags. Also here, I think you want to explicitly document the flag values here so the bindings don't rely on the Linux kernel code. I don't think there's a standard central file which documents them though, although I vaguely recall some discussion to create add them to gpio.txt? -- 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] MIPS: BCM63XX: switch to common clock and Device Tree
On 11/11/2012 05:50 AM, Jonas Gorski wrote: > Switch BCM63XX to the common clock framework and use clkdev for > providing clock name lookups for non-DT devices. > > Clocks can have a frequency and gate-bit, or none, in case they > are just provided for drivers expecting them to be present. > diff --git a/Documentation/devicetree/bindings/clock/bcm63xx-clock.txt > b/Documentation/devicetree/bindings/clock/bcm63xx-clock.txt A very minor nit, but it might be nice to add the DT binding documentation before (or as part of) the patches that use them (code that parses them, or using the bindings in .dts files) Of course, I'm relying on my email receive order, to judge this since the patch numbering didn't come through, so perhaps the patches are already set up this way... -- 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] spi: tegra: add spi driver for sflash controller
Nvidia's Tegra20 have the SPI (SFLASH) controller to
interface with spi flash device which is used for system
boot. Add the spi driver for this controller.
Signed-off-by: Laxman Dewangan
---
.../bindings/spi/nvidia,tegra20-sflash.txt | 26 +
drivers/spi/Kconfig|8 +
drivers/spi/Makefile |1 +
drivers/spi/spi-tegra20-sflash.c | 674
4 files changed, 709 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
create mode 100644 drivers/spi/spi-tegra20-sflash.c
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
new file mode 100644
index 000..8cf24f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
@@ -0,0 +1,26 @@
+NVIDIA Tegra20 SFLASH controller.
+
+Required properties:
+- compatible : should be "nvidia,tegra20-sflash".
+- reg: Should contain SFLASH registers location and length.
+- interrupts: Should contain SFLASH interrupts.
+- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+ request selector for this SFLASH controller.
+
+Recommended properties:
+- spi-max-frequency: Definition as per
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Example:
+
+spi@7000d600 {
+ compatible = "nvidia,tegra20-sflash";
+ reg = <0x7000c380 0x80>;
+ interrupts = <0 39 0x04>;
+ nvidia,dma-request-selector = < 16>;
+ spi-max-frequency = <2500>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+};
+
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 25290d9..3cbc9fb 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -385,6 +385,14 @@ config SPI_MXS
help
SPI driver for Freescale MXS devices.
+config SPI_TEGRA20_SFLASH
+ tristate "Nvidia Tegra20 Serial flash Controller"
+ depends on ARCH_TEGRA
+ help
+ SPI driver for Nvidia Tegra20 Serial flash Controller interface.
+ The main usecase of this controller is to use spi flash as boot
+ device.
+
config SPI_TEGRA20_SLINK
tristate "Nvidia Tegra20/Tegra30 SLINK Controller"
depends on ARCH_TEGRA && TEGRA20_APB_DMA
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index f87c0f1..9f6b3d8 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_SPI_SH_MSIOF)+= spi-sh-msiof.o
obj-$(CONFIG_SPI_SH_SCI) += spi-sh-sci.o
obj-$(CONFIG_SPI_SIRF) += spi-sirf.o
obj-$(CONFIG_SPI_STMP3XXX) += spi-stmp.o
+obj-$(CONFIG_SPI_TEGRA20_SFLASH) += spi-tegra20-sflash.o
obj-$(CONFIG_SPI_TEGRA20_SLINK)+= spi-tegra20-slink.o
obj-$(CONFIG_SPI_TI_SSP) += spi-ti-ssp.o
obj-$(CONFIG_SPI_TLE62X0) += spi-tle62x0.o
diff --git a/drivers/spi/spi-tegra20-sflash.c b/drivers/spi/spi-tegra20-sflash.c
new file mode 100644
index 000..db7ddc9
--- /dev/null
+++ b/drivers/spi/spi-tegra20-sflash.c
@@ -0,0 +1,674 @@
+/*
+ * SPI driver for Nvidia's Tegra20 Serial Flash Controller.
+ *
+ * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
Re: [RFC] MIPS: BCM63XX: add Device Tree clock definitions
On 11/11/2012 05:50 AM, Jonas Gorski wrote:
> Add definitions for the clocks found and used in all supported SoCs.
> diff --git a/arch/mips/bcm63xx/dts/bcm6328.dtsi
> b/arch/mips/bcm63xx/dts/bcm6328.dtsi
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + periph: pll {
> + compatible = "brcm,bcm63xx-clock";
> + #clock-cells = <0>;
> + clock-frequency = <5000>;
> + clock-output-names = "periph";
> + };
Here too, it seems like some reg properties would be required.
--
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] MIPS: BCM63XX: add Device Tree glue code for IRQ handling
On 11/11/2012 05:50 AM, Jonas Gorski wrote:
> Register IRQ domains through Device Tree for the internal and external
> interrupt controllers. Register the same IRQ ranges as previously to
> provide backward compatibility for non-DT drivers.
> diff --git a/Documentation/devicetree/bindings/mips/bcm63xx/epic.txt
> b/Documentation/devicetree/bindings/mips/bcm63xx/epic.txt
Rather than putting binding docs in an arch-specific directory, perhaps
put them into a device-type-specific directory, such as
bindings/interrupt-controller/brcm,bcm63xx-epic.txt?
> +- #interrupt-cells: <2>
> + This controller supports level and edge triggered interrupts. The
> + first cell is the interrupt number, the second is a 1:1 mapping to
> + the linux interrupt flags.
The DT documentation should be self-contained, and not reference
anything OS-specific. In this case, you could reference
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
for the interrupt flags.
> diff --git a/arch/mips/bcm63xx/dts/bcm6328.dtsi
> b/arch/mips/bcm63xx/dts/bcm6328.dtsi
> ranges = <0 0x1000 0x2>;
> compatible = "simple-bus";
> +
> + interrupt-parent = <>;
> +
> + perf@0 {
> + epic: interrupt-controller@18 {
Don't you need some reg properties in the perf and interrupt-controller
nodes so that the register address can be determined?
> + compatible = "brcm,bcm63xx-epic";
> + interrupt-controller;
> + #interrupt-cells = <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: [RFC] MIPS: BCM63XX: add simple Device Tree includes for all SoCs
On 11/11/2012 05:50 AM, Jonas Gorski wrote:
> Add simple Device Tree include files for all currently supported SoCs.
> These will be populated with device definitions as driver support
> gets added.
> arch/mips/bcm63xx/dts/bcm6328.dtsi | 30 ++
> arch/mips/bcm63xx/dts/bcm6338.dtsi | 30 ++
> arch/mips/bcm63xx/dts/bcm6345.dtsi | 30 ++
> arch/mips/bcm63xx/dts/bcm6348.dtsi | 30 ++
> arch/mips/bcm63xx/dts/bcm6358.dtsi | 33 +
> arch/mips/bcm63xx/dts/bcm6368.dtsi | 33 +
All of ARM, c6x, microblaze, openrisc, powerpc put device tree files
into arch/${arch}/boot/dts/ - should MIPS follow the same layout?
--
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] Add missing license for ioapic module.
config PCI_IOAPIC turned into a tristate in commit
b95a7bd700466c10fda84acbd33f70cf66ec91ce, but no module license is specified.
This adds the missing module license.
Signed-off-by: Andrew Cooks
---
drivers/pci/ioapic.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/ioapic.c b/drivers/pci/ioapic.c
index 205af8d..22436f7 100644
--- a/drivers/pci/ioapic.c
+++ b/drivers/pci/ioapic.c
@@ -125,3 +125,5 @@ static void __exit ioapic_exit(void)
module_init(ioapic_init);
module_exit(ioapic_exit);
+
+MODULE_LICENSE("GPL");
--
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: [PATCH 1/2] ARM: tegra: Add Tegra20 host1x support
On 11/12/2012 05:39 PM, Mark Zhang wrote:
> On 11/09/2012 09:20 PM, Thierry Reding wrote:
>> This commit adds the host1x node along with its children to the Tegra20
>> DTSI. Furthermore the OF auxiliary data table is updated to have proper
>> names assigned to the platform devices instantiated from the device
>> tree. Moreover, the clocks required by host1x and the two display
>> controllers are initialized and the pll_d frequency table is completed
>> with a few entries to support common HDMI and LVDS display modes.
>>
>> Signed-off-by: Thierry Reding
>> ---
>> arch/arm/boot/dts/tegra20.dtsi| 87
>> +++
>> arch/arm/mach-tegra/board-dt-tegra20.c| 9
>> arch/arm/mach-tegra/tegra20_clocks_data.c | 23
>> 3 files changed, 110 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
>> index 71a650d..2b4dec9 100644
>> --- a/arch/arm/boot/dts/tegra20.dtsi
>> +++ b/arch/arm/boot/dts/tegra20.dtsi
>> @@ -4,6 +4,93 @@
>> compatible = "nvidia,tegra20";
>> interrupt-parent = <>;
>>
>> + host1x {
>> + compatible = "nvidia,tegra20-host1x", "simple-bus";
>> + reg = <0x5000 0x00024000>;
>> + interrupts = <0 65 0x04 /* mpcore syncpt */
>> + 0 67 0x04>; /* mpcore general */
>> +
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + ranges = <0x5400 0x5400 0x0400>;
>> +
>> + mpe {
>> + compatible = "nvidia,tegra20-mpe";
>> + reg = <0x5404 0x0004>;
>> + interrupts = <0 68 0x04>;
>> + };
>> +
>> + vi {
>> + compatible = "nvidia,tegra20-vi";
>> + reg = <0x5408 0x0004>;
>> + interrupts = <0 69 0x04>;
>> + };
>> +
>> + epp {
>> + compatible = "nvidia,tegra20-epp";
>> + reg = <0x540c 0x0004>;
>> + interrupts = <0 70 0x04>;
>> + };
>> +
>> + isp {
>> + compatible = "nvidia,tegra20-isp";
>> + reg = <0x5410 0x0004>;
>> + interrupts = <0 71 0x04>;
>> + };
>> +
>> + gr2d {
>> + compatible = "nvidia,tegra20-gr2d";
>> + reg = <0x5414 0x0004>;
>> + interrupts = <0 72 0x04>;
>> + };
>> +
>> + gr3d {
>> + compatible = "nvidia,tegra20-gr3d";
>> + reg = <0x5418 0x0004>;
>> + };
>> +
>> + dc@5420 {
>> + compatible = "nvidia,tegra20-dc";
>> + reg = <0x5420 0x0004>;
>> + interrupts = <0 73 0x04>;
>> +
>> + rgb {
>> + status = "disabled";
>> + };
>> + };
>> +
>> + dc@5424 {
>> + compatible = "nvidia,tegra20-dc";
>> + reg = <0x5424 0x0004>;
>> + interrupts = <0 74 0x04>;
>> +
>> + rgb {
>> + status = "disabled";
>> + };
>> + };
>> +
>> + hdmi {
>> + compatible = "nvidia,tegra20-hdmi";
>> + reg = <0x5428 0x0004>;
>> + interrupts = <0 75 0x04>;
>> + status = "disabled";
>> + };
>> +
>> + tvo {
>> + compatible = "nvidia,tegra20-tvo";
>> + reg = <0x542c 0x0004>;
>> + interrupts = <0 76 0x04>;
>> + status = "disabled";
>> + };
>> +
>> + dsi {
>> + compatible = "nvidia,tegra20-dsi";
>> + reg = <0x5430 0x0004>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> timer@50004600 {
>> compatible = "arm,cortex-a9-twd-timer";
>> reg = <0x50040600 0x20>;
>> diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
>> b/arch/arm/mach-tegra/board-dt-tegra20.c
>> index 22f5a9b..1afbdd1 100644
>> --- a/arch/arm/mach-tegra/board-dt-tegra20.c
>> +++ b/arch/arm/mach-tegra/board-dt-tegra20.c
>> @@ -93,6 +93,12 @@ struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata
>> = {
>> OF_DEV_AUXDATA("nvidia,tegra20-slink", 0x7000D600, "spi_tegra.1",
>> NULL),
>> OF_DEV_AUXDATA("nvidia,tegra20-slink", 0x7000D800, "spi_tegra.2",
>> NULL),
>>
Re: [PATCH 2/2] ARM: tegra: Add Tegra30 host1x support
On 11/09/2012 09:20 PM, Thierry Reding wrote:
> This commit adds the host1x node along with its children to the Tegra30
> DTSI. Furthermore the OF auxiliary data table is updated to have proper
> names assigned to the platform devices instantiated from the device
> tree. Moreover, the clocks required by host1x and the two display
> controllers are setup and initialized.
>
> Signed-off-by: Thierry Reding
> ---
> arch/arm/boot/dts/tegra30.dtsi| 87
> +++
> arch/arm/mach-tegra/board-dt-tegra30.c| 10
> arch/arm/mach-tegra/tegra30_clocks_data.c | 11 ++--
> 3 files changed, 104 insertions(+), 4 deletions(-)
>
...
>
> diff --git a/arch/arm/mach-tegra/tegra30_clocks_data.c
> b/arch/arm/mach-tegra/tegra30_clocks_data.c
> index 7bc8b1d..210b8a4 100644
> --- a/arch/arm/mach-tegra/tegra30_clocks_data.c
> +++ b/arch/arm/mach-tegra/tegra30_clocks_data.c
> @@ -1132,14 +1132,14 @@ PERIPH_CLK(2d, "2d", NULL,
> 21, 0x15c, 52000, mux_pllm_pllc_pllp_plla, MUX
> PERIPH_CLK(vi_sensor, "tegra_camera", "vi_sensor",20,
> 0x1a8, 15000, mux_pllm_pllc_pllp_plla, MUX | DIV_U71 |
> PERIPH_NO_RESET);
> PERIPH_CLK(epp,"epp", NULL, 19,
> 0x16c, 52000, mux_pllm_pllc_pllp_plla, MUX | DIV_U71 | DIV_U71_INT);
> PERIPH_CLK(mpe,"mpe", NULL, 60,
> 0x170, 52000, mux_pllm_pllc_pllp_plla, MUX | DIV_U71 | DIV_U71_INT);
> -PERIPH_CLK(host1x, "host1x", NULL, 28, 0x180,
> 26000, mux_pllm_pllc_pllp_plla, MUX | DIV_U71 | DIV_U71_INT);
> +PERIPH_CLK(host1x, "tegra-host1x", NULL, 28, 0x180,
> 26000, mux_pllm_pllc_pllp_plla, MUX | DIV_U71 | DIV_U71_INT);
> PERIPH_CLK(cve,"cve", NULL, 49,
> 0x140, 25000, mux_pllp_plld_pllc_clkm, MUX | DIV_U71); /* requires
> min voltage */
> PERIPH_CLK(tvo,"tvo", NULL, 49,
> 0x188, 25000, mux_pllp_plld_pllc_clkm, MUX | DIV_U71); /* requires
> min voltage */
> PERIPH_CLK(dtv,"dtv", NULL, 79,
> 0x1dc, 25000, mux_clk_m, 0);
> -PERIPH_CLK(hdmi, "hdmi", NULL, 51, 0x18c,
> 14850, mux_pllp_pllm_plld_plla_pllc_plld2_clkm, MUX | MUX8 | DIV_U71);
> +PERIPH_CLK(hdmi, "tegra-hdmi", NULL, 51,
> 0x18c, 14850, mux_pllp_pllm_plld_plla_pllc_plld2_clkm, MUX | MUX8 |
> DIV_U71);
> PERIPH_CLK(tvdac, "tvdac",NULL, 53, 0x194,
> 22000, mux_pllp_plld_pllc_clkm, MUX | DIV_U71); /* requires min
> voltage */
> -PERIPH_CLK(disp1, "tegradc.0",NULL, 27, 0x138,
> 6, mux_pllp_pllm_plld_plla_pllc_plld2_clkm, MUX | MUX8);
> -PERIPH_CLK(disp2, "tegradc.1",NULL, 26, 0x13c,
> 6, mux_pllp_pllm_plld_plla_pllc_plld2_clkm, MUX | MUX8);
> +PERIPH_CLK(disp1, "tegra-dc.0", NULL, 27, 0x138,
> 6, mux_pllp_pllm_plld_plla_pllc_plld2_clkm, MUX | MUX8);
> +PERIPH_CLK(disp2, "tegra-dc.1", NULL, 26, 0x13c,
> 6, mux_pllp_pllm_plld_plla_pllc_plld2_clkm, MUX | MUX8);
> PERIPH_CLK(usbd, "fsl-tegra-udc",NULL, 22, 0,
> 48000, mux_clk_m, 0); /* requires min voltage */
> PERIPH_CLK(usb2, "tegra-ehci.1", NULL, 58, 0,
> 48000, mux_clk_m, 0); /* requires min voltage */
> PERIPH_CLK(usb3, "tegra-ehci.2", NULL, 59, 0,
> 48000, mux_clk_m, 0); /* requires min voltage */
> @@ -1337,6 +1337,9 @@ struct clk_duplicate tegra_clk_duplicates[] = {
> CLK_DUPLICATE("pll_p_out3", "tegra-i2c.2", "fast-clk"),
> CLK_DUPLICATE("pll_p_out3", "tegra-i2c.3", "fast-clk"),
> CLK_DUPLICATE("pll_p_out3", "tegra-i2c.4", "fast-clk"),
> + CLK_DUPLICATE("pll_p", "tegra-dc.0", "parent"),
> + CLK_DUPLICATE("pll_p", "tegra-dc.1", "parent"),
> + CLK_DUPLICATE("pll_d2_out0", "tegra-hdmi", "parent"),
> };
Why we need this? Set the parent of "tegra-dc.0" & "tegra-dc.1" to "pll_p"?
Mark
>
> struct clk *tegra_ptr_clks[] = {
> --
> 1.8.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" 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 arm-soc tree with the usb tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/configs/stamp9g20_defconfig between commit 77614e025061 ("arch: Change
defconfigs to point to g_mass_storage") from the usb tree and commit
2484575268e2 ("arm: at91: drop machine defconfig") from the arm-soc tree.
The latter deleted the file so I did that and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpQ1c9zR0Q9n.pgp
Description: PGP signature
linux-next: manual merge of the arm-soc tree with the pinctrl tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/tty/serial/atmel_serial.c between commit 784557decc48 ("tty:
atmel_serial: add pinctrl support") from the pinctrl tree and commit
bcd2360c1ff9 ("arm: at91: move platfarm_data to
include/linux/platform_data/atmel.h") from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/tty/serial/atmel_serial.c
index 65f891b,5660ec2..000
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@@ -39,7 -39,7 +39,8 @@@
#include
#include
#include
+#include
+ #include
#include
#include
pgpPj9TSAFm0x.pgp
Description: PGP signature
linux-next: manual merge of the arm-soc tree with the net-next tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/net/ethernet/cadence/at91_ether.c between various commits from
the net-next tree and commit bcd2360c1ff9 ("arm: at91: move platfarm_data
to include/linux/platform_data/atmel.h") from the arm-soc tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/ethernet/cadence/at91_ether.c
index e7a476c,35fc6edb..000
--- a/drivers/net/ethernet/cadence/at91_ether.c
+++ b/drivers/net/ethernet/cadence/at91_ether.c
@@@ -25,53 -31,728 +25,54 @@@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+ #include
-#include
-#include
-#include
-
-#include
-#include
-
-#include "at91_ether.h"
-
-#define DRV_NAME "at91_ether"
-#define DRV_VERSION "1.0"
-
-#define LINK_POLL_INTERVAL(HZ)
-
-/* . */
-
-/*
- * Read from a EMAC register.
- */
-static inline unsigned long at91_emac_read(struct at91_private *lp, unsigned
int reg)
-{
- return __raw_readl(lp->emac_base + reg);
-}
-
-/*
- * Write to a EMAC register.
- */
-static inline void at91_emac_write(struct at91_private *lp, unsigned int reg,
unsigned long value)
-{
- __raw_writel(value, lp->emac_base + reg);
-}
-
-/* ... PHY INTERFACE ... */
-
-/*
- * Enable the MDIO bit in MAC control register
- * When not called from an interrupt-handler, access to the PHY must be
- * protected by a spinlock.
- */
-static void enable_mdi(struct at91_private *lp)
-{
- unsigned long ctl;
-
- ctl = at91_emac_read(lp, AT91_EMAC_CTL);
- at91_emac_write(lp, AT91_EMAC_CTL, ctl | AT91_EMAC_MPE);/*
enable management port */
-}
-
-/*
- * Disable the MDIO bit in the MAC control register
- */
-static void disable_mdi(struct at91_private *lp)
-{
- unsigned long ctl;
-
- ctl = at91_emac_read(lp, AT91_EMAC_CTL);
- at91_emac_write(lp, AT91_EMAC_CTL, ctl & ~AT91_EMAC_MPE); /*
disable management port */
-}
-
-/*
- * Wait until the PHY operation is complete.
- */
-static inline void at91_phy_wait(struct at91_private *lp)
-{
- unsigned long timeout = jiffies + 2;
-
- while (!(at91_emac_read(lp, AT91_EMAC_SR) & AT91_EMAC_SR_IDLE)) {
- if (time_after(jiffies, timeout)) {
- printk("at91_ether: MIO timeout\n");
- break;
- }
- cpu_relax();
- }
-}
-
-/*
- * Write value to the a PHY register
- * Note: MDI interface is assumed to already have been enabled.
- */
-static void write_phy(struct at91_private *lp, unsigned char phy_addr,
unsigned char address, unsigned int value)
-{
- at91_emac_write(lp, AT91_EMAC_MAN, AT91_EMAC_MAN_802_3 | AT91_EMAC_RW_W
- | ((phy_addr & 0x1f) << 23) | (address << 18) | (value &
AT91_EMAC_DATA));
-
- /* Wait until IDLE bit in Network Status register is cleared */
- at91_phy_wait(lp);
-}
-
-/*
- * Read value stored in a PHY register.
- * Note: MDI interface is assumed to already have been enabled.
- */
-static void read_phy(struct at91_private *lp, unsigned char phy_addr,
unsigned char address, unsigned int *value)
-{
- at91_emac_write(lp, AT91_EMAC_MAN, AT91_EMAC_MAN_802_3 | AT91_EMAC_RW_R
- | ((phy_addr & 0x1f) << 23) | (address << 18));
-
- /* Wait until IDLE bit in Network Status register is cleared */
- at91_phy_wait(lp);
-
- *value = at91_emac_read(lp, AT91_EMAC_MAN) & AT91_EMAC_DATA;
-}
-
-/* ... PHY MANAGEMENT .. */
-
-/*
- * Access the PHY to determine the current link speed and mode, and update the
- * MAC accordingly.
- * If no link or auto-negotiation is busy, then no changes are made.
- */
-static void update_linkspeed(struct net_device *dev, int silent)
-{
- struct at91_private *lp = netdev_priv(dev);
- unsigned int bmsr, bmcr, lpa, mac_cfg;
- unsigned int speed, duplex;
-
- if (!mii_link_ok(>mii)) { /* no link */
- netif_carrier_off(dev);
- if (!silent)
- printk(KERN_INFO "%s: Link down.\n", dev->name);
- return;
- }
-
- /* Link up, or auto-negotiation still in progress */
- read_phy(lp, lp->phy_address, MII_BMSR, );
- read_phy(lp, lp->phy_address, MII_BMCR, );
- if (bmcr & BMCR_ANENABLE) { /*
AutoNegotiation is enabled */
- if (!(bmsr & BMSR_ANEGCOMPLETE))
- return; /* Do nothing - another
interrupt generated when negotiation complete */
-
- read_phy(lp, lp->phy_address, MII_LPA, );
-
linux-next: manual merge of the arm-soc tree with the usb tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/configs/afeb9260_defconfig between commit 77614e025061 ("arch:
Change defconfigs to point to g_mass_storage") from the usb tree and
commit 2484575268e2 ("arm: at91: drop machine defconfig") from the
arm-soc tree.
The latter deletes the file, so I did that and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpXrro0pidd6.pgp
Description: PGP signature
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, On Fri, Nov 9, 2012 at 3:22 PM, Grant Likely wrote: >> (2) >> Also this discussed a while back but at some point is going to brought >> up again- loading of dt fragment directly from EEPROM and merging at >> run time. If we were to implement this in kernel, we would have to add >> cape specific EEPROM reading code, merge the tree before it is >> unflattened and parse. > > Unless it is required for boot to userspace I'm not considering > merging before userspace starts. That's well after the tree is > unflattened into the live form. If it is require to boot then I agree > that is should be done in firmware. I see zero problem with having a > beaglebone specific cape driver that knows to read the eeprom and > request a specific configuration file. Heck, the kernel doesn't even > need to parse the eeprom data. It can be read from userspace and > userspace decides which overlay to provide. There's nothing stopping > userspace from reading the eeprom, looking up the correct dts for the > board, downloading the file from the Internet, compiling it with dtc > and installing it and yes that is getting a little extreme. Actually, I was speaking of the case where today we read EEPROM anyway for capes before userspace, so it would convenient do the overlay this way. Further, userspace doesn't have to do any parsing as kernel/u-boot could blindly load the dtb overlay directly from EEPROM regardless of which cape. So we don't have do any revision detection and dtb search, the dtb itself being in the EEPROM. That way no matter what the userspace is, the cape hardware is already configured and ready to use by userspace. This might be a corner-case just for beaglebone though, and if requesting overlay from userspace is a more general solution for all usecases, then probably we should go with that approach. OTOH, I guess there's no harm in doing some overlays from kernel for some cases, and userspace for others. >> The code that does >> the tree walking can then just strcmp the node name while it walks the >> tree instead of having to find a node with a phandle number. I guess >> the reason is phandles are small to store as data values. Another >> approach can be to arrange the string block in alphabetical order >> (unless it already is), and store phandle as index of the node name >> referenced relative to the starting of the strong block. This will not >> affect nodes in dtb being moved around since they will still have the >> same index value. the problem being adding or removing nodes Changes >> the index of all other nodes in the string block as well.. Hmm. > > And that still doesn't help find all the phandle locations in the tree > for doing fixups. It would need to be a table of > nodes+properties+offsets that contain phandles for fixup to work, but > I shy away from that approach because I think it will be fragile. I guess this approach (which wouldn't work for other reasons) was intended to serve the same purpose as Hashing, having a phandle that doesn't easily change hence not requiring overlay fixups. Actually I'm a bit confused if how maintaining a list of name/node-paths for fix up will even work, because node names are not unique as we discussed. Also node paths can change, so what will the overlay dtb store in its fixup table (say there is one)? A table of node,properties etc as you mentioned might not be unique as there can be 2 nodes with same name and properties. Also if we use node path, instead of node name, in this table, then moving nodes around wont be possible as the fixup table will be pointing to node path references that have now changed- how will the kernel now what's the node's new actual path, say, if there are 2 nodes with the same name? Only thing possible is, to do a _mandatory_ recompile of overlay dtb if a node's path changes. Would be you be in agreement that- When a node's path changes in base dtb, Overlays have to be recompiled and a new fixup table has to be created, or a new hash has to be generated out of the new node path regardless. So moving nodes around in base dtb can't be dynamically accommodated without recompiling overlay. Considering the above is ok, the only 2 approaches I can see for phandle resolutions are: (1) hashing of the full node path and avoiding runtime fixups. (2) Using today's linear phandle increment approach, maintaining a table in the overlay with the key as 'node path' and value as 'phandle fixup offset', and then doing runtime fixups. I believe (2) is considered fragile and it does the same thing as (1) except that (2) can even handle collisions but at the cost of storing the full node path in the overlay's fixup table. So (1) looks like our only possible and meaningful approach. Do you agree with this analysis? Or, maybe I am missing something. Regards, Joel -- 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
linux-next: manual merge of the staging tree with the mfd tree
Hi Greg,
Today's linux-next merge of the staging tree got conflicts in
drivers/iio/adc/Kconfig and drivers/iio/adc/Makefile between commit
5e53a69b44e8 ("IIO : ADC: tiadc: Add support of TI's ADC driver") from
the mfd tree and commit 168c9d95a940 ("iio:adc:max1363 move from
staging") from the staging tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/iio/adc/Kconfig
index 1401ed1,ef5200a..000
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@@ -60,11 -73,22 +73,29 @@@ config LP8788_AD
help
Say yes here to build support for TI LP8788 ADC.
+ config MAX1363
+ tristate "Maxim max1363 ADC driver"
+ depends on I2C
+ select IIO_TRIGGER
+ select MAX1363_RING_BUFFER
+ select IIO_BUFFER
+ select IIO_KFIFO_BUF
+ help
+ Say yes here to build support for many Maxim i2c analog to digital
+ converters (ADC). (max1361, max1362, max1363, max1364, max1036,
+ max1037, max1038, max1039, max1136, max1136, max1137, max1138,
+ max1139, max1236, max1237, max11238, max1239, max11600, max11601,
+ max11602, max11603, max11604, max11605, max11606, max11607,
+ max11608, max11609, max11610, max11611, max11612, max11613,
+ max11614, max11615, max11616, max11617, max11644, max11645,
+ max11646, max11647) Provides direct access via sysfs and buffered
+ data via the iio dev interface.
+
+config TI_AM335X_ADC
+ tristate "TI's ADC driver"
+ depends on MFD_TI_AM335X_TSCADC
+ help
+Say yes here to build support for Texas Instruments ADC
+driver which is also a MFD client.
+
endmenu
diff --cc drivers/iio/adc/Makefile
index 4410a90,54ac7bb..000
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@@ -6,6 -6,7 +6,8 @@@ obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigm
obj-$(CONFIG_AD7266) += ad7266.o
obj-$(CONFIG_AD7476) += ad7476.o
obj-$(CONFIG_AD7791) += ad7791.o
+ obj-$(CONFIG_AD7887) += ad7887.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
+ obj-$(CONFIG_MAX1363) += max1363.o
+obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
pgpW9fCQitQmQ.pgp
Description: PGP signature
Re: [PATCH v3 0/2] x86: clear vmcss on all cpus when doing kdump if necessary
Hello Marcelo, Do you have any comments about this version? Thanks Zhang 于 2012年10月31日 11:30, zhangyanfei 写道: > Currently, kdump just makes all the logical processors leave VMX operation by > executing VMXOFF instruction, so any VMCSs active on the logical processors > may > be corrupted. But, sometimes, we need the VMCSs to debug guest images > contained > in the host vmcore. To prevent the corruption, we should VMCLEAR the VMCSs > before > executing the VMXOFF instruction. > > The patch set provides a way to VMCLEAR vmcss related to guests on all cpus > before > executing the VMXOFF when doing kdump. This is used to ensure the VMCSs in the > vmcore updated and non-corrupted. > > Changelog from v2 to v3: > 1. remove unnecessary conditions in function >cpu_emergency_clear_loaded_vmcss as Marcelo suggested. > > Changelog from v1 to v2: > 1. remove the sysctl and clear VMCSs unconditionally. > > Zhang Yanfei (2): > x86/kexec: VMCLEAR vmcss on all cpus if necessary > KVM: make crash_clear_loaded_vmcss valid when loading kvm_intel > module > > arch/x86/include/asm/kexec.h |2 ++ > arch/x86/kernel/crash.c | 25 + > arch/x86/kvm/vmx.c |9 + > 3 files changed, 36 insertions(+), 0 deletions(-) > -- > 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-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: [sqlite] light weight write barriers
杨苏立 Yang Su Li, on 11/10/2012 11:25 PM wrote: SATA's Native Command Queuing (NCQ) is not equivalent; this allows the drive to reorder requests (in particular read requests) so they can be serviced more efficiently, but it does *not* allow the OS to specify a partial, relative ordering of requests. And so? If SATA can't do it, does it mean that nobody else can't do it too? I know a plenty of non-SATA devices, which can do the ordering requirements you need. I would be very much interested in what kind of device support this kind of "topological order", and in what settings they are typically used. Does modern flash/SSD (esp. which are used on smartphones) support this? If you could point me to some information about this, that would be very much appreciated. I don't think storage in smartphone can support such advanced functionality, because it tends to be the cheapest, hence the simplest. But many modern Enterprise SAS drives can do it, because for those customers performance is the key requirement. Unfortunately, I'm not sure I can name exact brands and models, because I had my knowledge from NDA'ed docs, so this info can be also NDA'ed. Vlad -- 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: [sqlite] light weight write barriers
Richard Hipp, on 11/02/2012 08:24 AM wrote: SQLite cares. SQLite is an in-process, transaction, zero-configuration database that is estimated to be used by over 1 million distinct applications and to be have over 2 billion deployments. SQLite uses ordinary disk files in ordinary directories, often selected by the end-user. There is no system administrator with SQLite, so there is no opportunity to use a dedicated filesystem with special mount options. SQLite uses fsync() as a write barrier to assure consistency following a power loss. In addition, we do everything we can to maximize the amount of time after the fsync() before we actually do another write where order matters, in the hopes that the writes will still be ordered on platforms where fsync() is ignored for whatever reason. Even so, we believe we could get a significant performance boost and reliability improvement if we had a reliable write barrier. I would suggest you to forget word "barrier" for productivity sake. You don't want barriers and confusion they bring. You want instead access to storage accelerated cache sync, commands ordering and atomic attributes/operations. See my other today's e-mail about those. Vlad -- 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: [sqlite] light weight write barriers
Alan Cox, on 11/02/2012 08:33 AM wrote: b) most drives will internally re-order requests anyway They will but only as permitted by the commands queued, so you have some control depending upon the interface capabilities. c) cheap drives won't support barriers Barriers are pretty much universal as you need them for power off ! I'm afraid, no storage (drives, if you like this term more) at the moment supports barriers and, as far as I know the storage history, has never supported. Instead, what storage does support in this area are: 1. Cache flushing facilities: FUA, SYNCHRONIZE CACHE, etc. 2. Commands ordering facilities: commands attributes (ORDERED, SIMPLE, etc.), ACA, etc. 3. Atomic commands, e.g. scattered writes, which allow to write data in several separate not adjacent blocks in an atomic manner, i.e. guarantee that either all blocks are written or none at all. This is a relatively new functionality, natural for flash storage with its COW internals. Obviously, using such atomic write commands, an application or a file system don't need any journaling anymore. FusionIO reported that after they modified MySQL to use them, they had 50% performance increase. Note, that those 3 facilities are ORTHOGONAL, i.e. can be used independently, including on the same request. That is the root cause why barrier concept is so evil. If you specify a barrier, how can you say what kind actual action you really want from the storage: cache flush? Or ordered write? Or both? This is why relatively recent removal of barriers from the Linux kernel (http://lwn.net/Articles/400541/) was a big step ahead. The next logical step should be to allow ORDERED attribute for requests be accelerated by ORDERED commands of the storage, if it supports them. If not, fall back to the existing queue draining. Actually, I'm wondering, why barriers concept is so sticky in the Linux world? A simple Google search shows that only Linux uses this concept for storage. And 2 years passed, since they were removed from the kernel, but people still discuss barriers as if they are here. Vlad -- 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: [sqlite] light weight write barriers
Howard Chu, on 11/01/2012 08:38 PM wrote: Alan Cox wrote: How about that recently preliminary infrastructure to send ORDERED commands instead of queue draining was deleted from the kernel, because "there's no difference where to drain the queue, on the kernel or the storage side"? Send patches. Isn't any type of kernel-side ordering an exercise in futility, since a) the kernel has no knowledge of the disk's actual geometry b) most drives will internally re-order requests anyway c) cheap drives won't support barriers This is why it is so important for performance to use all storage capabilities. Particularly, ORDERED commands instead of trying to pretend be smarter, than the storage, doing queue draining. Vlad -- 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 usb tree with the usb.current tree
Hi Greg,
Today's linux-next merge of the usb tree got a conflict in
drivers/usb/musb/ux500.c between commit 9a65d162e449 ("usb: musb: ux500:
fix 'musbid' undeclared error in ux500_remove()") from the usb.current
tree and commit 2f7711642559 ("usb: musb: remove hand-crafted id
handling") from the usb tree.
The latter supercedes the former so I used that and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp82Jeke1AQn.pgp
Description: PGP signature
[PATCH ] tbfadt.c: output warning only when 64bit 32bit address of FACS/DSDT all have value but not equal to each other
Hi, Len, Robert,
Please help to check the following patch, add more conditions
when validate the 64bit 32bit FACS/DSDT address in FADT to follow ACPI
spec, In the meantime, keep the compatibility and latitude.
Thanks,
Ethan
>From c1116211a7b329c26b0370565c36b084ceb08f71 Mon Sep 17 00:00:00 2001
From: ethan.zhao
Date: Tue, 13 Nov 2012 22:21:12 -0800
Subject: [PATCH 642/642] To follow the ACPI spec 3,4&5 and keep the
compatibility and latitude,only
output mismatch warning when 64bit address and 32bit address of
FACS/DSDT are all
valid but not equal to each other.
Signed-off-by: ethan.zhao
---
drivers/acpi/acpica/tbfadt.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
index 3906518..f23f512 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -512,7 +512,7 @@ static void acpi_tb_validate_fadt(void)
* the 32-bit and 64-bit address fields
(FIRMWARE_CTRL/X_FIRMWARE_CTRL and
* DSDT/X_DSDT) would indicate the presence of two FACS or two
DSDT tables.
*/
- if (acpi_gbl_FADT.facs &&
+ if ((acpi_gbl_FADT.facs && acpi_gbl_FADT.Xfacs) &&
(acpi_gbl_FADT.Xfacs != (u64)acpi_gbl_FADT.facs)) {
ACPI_BIOS_WARNING((AE_INFO,
"32/64X FACS address mismatch in FADT - "
@@ -523,7 +523,7 @@ static void acpi_tb_validate_fadt(void)
acpi_gbl_FADT.Xfacs = (u64)acpi_gbl_FADT.facs;
}
- if (acpi_gbl_FADT.dsdt &&
+ if ((acpi_gbl_FADT.dsdt && acpi_gbl_FADT.Xdsdt) &&
(acpi_gbl_FADT.Xdsdt != (u64)acpi_gbl_FADT.dsdt)) {
ACPI_BIOS_WARNING((AE_INFO,
"32/64X DSDT address mismatch in FADT - "
--
1.7.1
To-follow-the-ACPI-spec-3-4-5-and-keep-the-compatibi.patch
Description: Binary data
Re: [CPU hotplug, __disable_runtime] kernel BUG at kernel/sched/rt.c:687!
Hi Peter and Ingo, 2012/11/5 Fengguang Wu : > Greetings, > > I got a rather hard to reproduce/bisect oops when doing CPU hotplug > testing: > > [ 480.327742] CPU0 attaching NULL sched-domain. > [ 480.329408] [ cut here ] > [ 480.330355] kernel BUG at /c/kernel-tests/src/stable/kernel/sched/rt.c:687! > [ 480.330355] invalid opcode: [#1] SMP DEBUG_PAGEALLOC > [ 480.330355] Modules linked in: > [ 480.330355] CPU 1 > [ 480.330355] Pid: 3007, comm: 01-cpu-hotplug Not tainted > 3.7.0-rc3-00017-g1a303f5 #2502 Bochs Bochs > [ 480.330355] RIP: 0010:[] [] > __disable_runtime+0x188/0x1c2 > [ 480.330355] RSP: 0018:8800199cbad8 EFLAGS: 00010082 > [ 480.330355] RAX: 810a6796 RBX: 88001f3d3b40 RCX: > 0005 > [ 480.330355] RDX: 81a5ff61 RSI: 0092 RDI: > 0046 > [ 480.330355] RBP: 8800199cbb38 R08: 06fc R09: > 000c > [ 480.330355] R10: 000c R11: 8800168cac88 R12: > 0040 > [ 480.330355] R13: 88001f3d4358 R14: 001d3b40 R15: > fd050f80 > [ 480.330355] FS: 7f2f660d9700() GS:88001f40() > knlGS: > [ 480.330355] CS: 0010 DS: ES: CR0: 8005003b > [ 480.330355] CR2: 7f2f65aab830 CR3: 184a1000 CR4: > 06e0 > [ 480.330355] DR0: DR1: DR2: > > [ 480.330355] DR3: DR6: 0ff0 DR7: > 0400 > [ 480.330355] Process 01-cpu-hotplug (pid: 3007, threadinfo > 8800199ca000, task 8800168ca3e0) > [ 480.330355] Stack: > [ 480.330355] 8800199cbb58 8800168cac18 88001f3d3b58 > 880018544a58 > [ 480.330355] 88001f3d3cb8 0040 8800199cbb58 > 88001f3d3b40 > [ 480.330355] 81a931d0 824086b0 880018544a60 > > [ 480.330355] Call Trace: > [ 480.330355] [] rq_offline_rt+0x74/0x96 > [ 480.330355] [] set_rq_offline.part.37+0x2a/0x81 > [ 480.330355] [] rq_attach_root+0x85/0x193 > [ 480.330355] [] cpu_attach_domain+0x180/0x228 > [ 480.330355] [] partition_sched_domains+0x157/0x350 > [ 480.330355] [] ? partition_sched_domains+0x109/0x350 > [ 480.330355] [] ? trace_hardirqs_on_caller+0x125/0x181 > [ 480.330355] [] cpuset_update_active_cpus+0x10c/0x117 > [ 480.330355] [] ? keep_working+0x2d/0x2d > [ 480.330355] [] cpuset_cpu_inactive+0x20/0x3f > [ 480.330355] [] notifier_call_chain+0x65/0x95 > [ 480.330355] [] __raw_notifier_call_chain+0xe/0x10 > [ 480.330355] [] __cpu_notify+0x20/0x37 > [ 480.330355] [] _cpu_down+0xa4/0x26d > [ 480.330355] [] cpu_down+0x28/0x3c > [ 480.330355] [] store_online+0x3e/0x8f > [ 480.330355] [] dev_attr_store+0x18/0x24 > [ 480.330355] [] sysfs_write_file+0xee/0x126 > [ 480.330355] [] vfs_write+0xa6/0x152 > [ 480.330355] [] sys_write+0x4c/0x80 > [ 480.330355] [] tracesys+0xdd/0xe2 > [ 480.330355] Code: 00 00 00 49 63 d4 e8 e1 b8 39 00 3b 05 73 97 ff 00 48 89 > 45 c8 41 89 c4 0f 8c 2c ff ff ff 4c 89 ef e8 72 8d 9b 00 4d 85 ff 74 02 <0f> > 0b 48 c7 83 10 08 00 00 ff ff ff ff 4c 89 ef c7 83 00 08 00 > [ 480.330355] RIP [] __disable_runtime+0x188/0x1c2 > [ 480.330355] RSP > > Thanks, > Fengguang I have met the same issue on Marvell SOC. Would you please take a look? Thanks. Best Regards, Neil Zhang -- 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 03/17] cgroup: open-code cgroup_create_dir()
The operation order of cgroup creation is about to change and
cgroup_create_dir() is more of a hindrance than a proper abstraction.
Open-code it by moving the parent nlink adjustment next to self nlink
adjustment in cgroup_create_file() and the rest to cgroup_create().
This patch doesn't introduce any behavior change.
Signed-off-by: Tejun Heo
---
kernel/cgroup.c | 30 +-
1 file changed, 5 insertions(+), 25 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index ed0e177..b042673 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2652,6 +2652,7 @@ static int cgroup_create_file(struct dentry *dentry,
umode_t mode,
/* start off with i_nlink == 2 (for "." entry) */
inc_nlink(inode);
+ inc_nlink(dentry->d_parent->d_inode);
/* start with the directory inode held, so that we can
* populate it without racing with another mkdir */
@@ -2666,30 +2667,6 @@ static int cgroup_create_file(struct dentry *dentry,
umode_t mode,
return 0;
}
-/*
- * cgroup_create_dir - create a directory for an object.
- * @cgrp: the cgroup we create the directory for. It must have a valid
- *->parent field. And we are going to fill its ->dentry field.
- * @dentry: dentry of the new cgroup
- * @mode: mode to set on new directory.
- */
-static int cgroup_create_dir(struct cgroup *cgrp, struct dentry *dentry,
- umode_t mode)
-{
- struct dentry *parent;
- int error = 0;
-
- parent = cgrp->parent->dentry;
- error = cgroup_create_file(dentry, S_IFDIR | mode, cgrp->root->sb);
- if (!error) {
- dentry->d_fsdata = cgrp;
- inc_nlink(parent->d_inode);
- rcu_assign_pointer(cgrp->dentry, dentry);
- }
-
- return error;
-}
-
/**
* cgroup_file_mode - deduce file mode of a control file
* @cft: the control file in question
@@ -4138,10 +4115,13 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
list_add_tail_rcu(>sibling, >parent->children);
root->number_of_cgroups++;
- err = cgroup_create_dir(cgrp, dentry, mode);
+ err = cgroup_create_file(dentry, S_IFDIR | mode, sb);
if (err < 0)
goto err_remove;
+ dentry->d_fsdata = cgrp;
+ rcu_assign_pointer(cgrp->dentry, dentry);
+
for_each_subsys(root, ss) {
/* each css holds a ref to the cgroup's dentry */
dget(dentry);
--
1.7.11.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 04/17] cgroup: create directory before linking while creating a new cgroup
While creating a new cgroup, cgroup_create() links the newly allocated
cgroup into various places before trying to create its directory.
Because cgroup life-cycle is tied to the vfs objects, this makes it
impossible to use cgroup_rmdir() for rolling back creation - the
removal logic depends on having full vfs objects.
This patch moves directory creation above linking and collect linking
operations to one place. This allows directory creation failure to
share error exit path with css allocation failures and any failure
sites afterwards (to be added later) can use cgroup_rmdir() logic to
undo creation.
It also removes the need to check whether cgroup->dentry is %NULL in
cgroup_path. If a cgroup is visible, its dentry is guaranteed to be
visible too.
Note that this also makes the memory barriers around cgroup->dentry,
which currently is misleadingly using RCU operations, unnecessary.
This will be handled in the next patch.
While at it, locking BUG_ON() on i_mutex is converted to
lockdep_assert_held().
Signed-off-by: Tejun Heo
---
kernel/cgroup.c | 32 +---
1 file changed, 13 insertions(+), 19 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index b042673..40707cd 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1760,7 +1760,7 @@ int cgroup_path(const struct cgroup *cgrp, char *buf, int
buflen)
struct dentry *dentry = rcu_dereference_check(cgrp->dentry,
cgroup_lock_is_held());
- if (!dentry || cgrp == dummytop) {
+ if (cgrp == dummytop) {
/*
* Inactive subsystems have no dentry for their root
* cgroup
@@ -4112,15 +4112,22 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
}
}
- list_add_tail_rcu(>sibling, >parent->children);
- root->number_of_cgroups++;
-
+ /*
+* Create directory. cgroup_create_file() returns with the new
+* directory locked on success so that it can be populated without
+* dropping cgroup_mutex.
+*/
err = cgroup_create_file(dentry, S_IFDIR | mode, sb);
if (err < 0)
- goto err_remove;
+ goto err_destroy;
+ lockdep_assert_held(>d_inode->i_mutex);
+ /* allocation complete, commit to creation */
dentry->d_fsdata = cgrp;
rcu_assign_pointer(cgrp->dentry, dentry);
+ list_add_tail(>allcg_node, >allcg_list);
+ list_add_tail_rcu(>sibling, >parent->children);
+ root->number_of_cgroups++;
for_each_subsys(root, ss) {
/* each css holds a ref to the cgroup's dentry */
@@ -4131,11 +4138,6 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
ss->post_create(cgrp);
}
- /* The cgroup directory was pre-locked for us */
- BUG_ON(!mutex_is_locked(>dentry->d_inode->i_mutex));
-
- list_add_tail(>allcg_node, >allcg_list);
-
err = cgroup_populate_dir(cgrp, true, root->subsys_mask);
/* If err < 0, we have a half-filled directory - oh well ;) */
@@ -4144,20 +4146,12 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
return 0;
- err_remove:
-
- list_del_rcu(>sibling);
- root->number_of_cgroups--;
-
- err_destroy:
-
+err_destroy:
for_each_subsys(root, ss) {
if (cgrp->subsys[ss->subsys_id])
ss->destroy(cgrp);
}
-
mutex_unlock(_mutex);
-
/* Release the reference count that we took on the superblock */
deactivate_super(sb);
err_free:
--
1.7.11.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 09/17] cgroup: lock cgroup_mutex in cgroup_init_subsys()
Make cgroup_init_subsys() grab cgroup_mutex while initializing a subsystem so that all helpers and callbacks are called under the context they expect. This isn't strictly necessary as cgroup_init_subsys() doesn't race with anybody but will allow adding lockdep assertions. Signed-off-by: Tejun Heo --- kernel/cgroup.c | 4 1 file changed, 4 insertions(+) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 6df17cb..76f1a01 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -4317,6 +4317,8 @@ static void __init cgroup_init_subsys(struct cgroup_subsys *ss) printk(KERN_INFO "Initializing cgroup subsys %s\n", ss->name); + mutex_lock(_mutex); + /* init base cftset */ cgroup_init_cftsets(ss); @@ -4346,6 +4348,8 @@ static void __init cgroup_init_subsys(struct cgroup_subsys *ss) if (ss->post_create) ss->post_create(dummytop); + mutex_unlock(_mutex); + /* this function shouldn't be used with modular subsystems, since they * need to register a subsys_id, among other things */ BUG_ON(ss->module); -- 1.7.11.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 10/17] cgroup: fix harmless bugs in cgroup_load_subsys() fail path and cgroup_unload_subsys()
* If idr init fails, cgroup_load_subsys() cleared dummytop->subsys[]
before calilng ->destroy() making CSS inaccessible to the callback,
and didn't unlink ss->sibling. As no modular controller uses
->use_id, this doesn't cause any actual problems.
* cgroup_unload_subsys() was forgetting to free idr, call
->pre_destroy() and clear ->active. As there currently is no
modular controller which uses ->use_id, ->pre_destroy() or ->active,
this doesn't cause any actual problems.
Signed-off-by: Tejun Heo
---
kernel/cgroup.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 76f1a01..c5368c0 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4420,9 +4420,10 @@ int __init_or_module cgroup_load_subsys(struct
cgroup_subsys *ss)
if (ss->use_id) {
int ret = cgroup_init_idr(ss, css);
if (ret) {
- dummytop->subsys[ss->subsys_id] = NULL;
ss->destroy(dummytop);
+ dummytop->subsys[ss->subsys_id] = NULL;
subsys[ss->subsys_id] = NULL;
+ list_del_init(>sibling);
mutex_unlock(_mutex);
return ret;
}
@@ -4490,7 +4491,19 @@ void cgroup_unload_subsys(struct cgroup_subsys *ss)
*/
BUG_ON(ss->root != );
+ /* ->pre_destroy() should be called outside cgroup_mutex for now */
+ if (ss->pre_destroy)
+ ss->pre_destroy(dummytop);
+
mutex_lock(_mutex);
+
+ ss->active = 0;
+
+ if (ss->use_id) {
+ idr_remove_all(>idr);
+ idr_destroy(>idr);
+ }
+
/* deassign the subsys_id */
subsys[ss->subsys_id] = NULL;
--
1.7.11.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 06/17] cgroup: remove duplicate RCU free on struct cgroup
struct cgroup is made RCU-safe by synchronize_rcu() in cgroup_diput().
There is no reason to use RCU safe kfree on it after it. Remove
cgroup->rcu_head and use kfree() instead of kfree_rcu() in
cgroup_diput().
Signed-off-by: Tejun Heo
---
include/linux/cgroup.h | 3 ---
kernel/cgroup.c| 2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index d605857..9dcbfa1 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -196,9 +196,6 @@ struct cgroup {
struct list_head pidlists;
struct mutex pidlist_mutex;
- /* For RCU-protected deletion */
- struct rcu_head rcu_head;
-
/* List of events which userspace want to receive */
struct list_head event_list;
spinlock_t event_list_lock;
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 278752e..a91e7ad 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -893,7 +893,7 @@ static void cgroup_diput(struct dentry *dentry, struct
inode *inode)
simple_xattrs_free(>xattrs);
- kfree_rcu(cgrp, rcu_head);
+ kfree(cgrp);
} else {
struct cfent *cfe = __d_cfe(dentry);
struct cgroup *cgrp = dentry->d_parent->d_fsdata;
--
1.7.11.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 02/17] cgroup: initialize cgrp->allcg_node in init_cgroup_housekeeping()
Not strictly necessary but it's annoying to have uninitialized list_head around. Signed-off-by: Tejun Heo --- kernel/cgroup.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index d0803f0..ed0e177 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -1381,6 +1381,7 @@ static void init_cgroup_housekeeping(struct cgroup *cgrp) INIT_LIST_HEAD(>children); INIT_LIST_HEAD(>files); INIT_LIST_HEAD(>css_sets); + INIT_LIST_HEAD(>allcg_node); INIT_LIST_HEAD(>release_list); INIT_LIST_HEAD(>pidlists); mutex_init(>pidlist_mutex); -- 1.7.11.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 07/17] cgroup: make CSS_* flags bit masks instead of bit positions
Currently, CSS_* flags are defined as bit positions and manipulated
using atomic bitops. There's no reason to use atomic bitops for them
and bit positions are clunkier to deal with than bit masks. Make
CSS_* bit masks instead and use the usual C bitwise operators to
access them.
Signed-off-by: Tejun Heo
---
include/linux/cgroup.h | 8
kernel/cgroup.c| 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 9dcbfa1..e9f07ef 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -81,7 +81,7 @@ struct cgroup_subsys_state {
/* bits in struct cgroup_subsys_state flags field */
enum {
- CSS_ROOT, /* This CSS is the root of the subsystem */
+ CSS_ROOT= (1 << 0), /* this CSS is the root of the subsystem */
};
/* Caller must verify that the css is not for root cgroup */
@@ -100,7 +100,7 @@ static inline void __css_get(struct cgroup_subsys_state
*css, int count)
static inline void css_get(struct cgroup_subsys_state *css)
{
/* We don't need to reference count the root state */
- if (!test_bit(CSS_ROOT, >flags))
+ if (!(css->flags & CSS_ROOT))
__css_get(css, 1);
}
@@ -113,7 +113,7 @@ static inline void css_get(struct cgroup_subsys_state *css)
extern bool __css_tryget(struct cgroup_subsys_state *css);
static inline bool css_tryget(struct cgroup_subsys_state *css)
{
- if (test_bit(CSS_ROOT, >flags))
+ if (css->flags & CSS_ROOT)
return true;
return __css_tryget(css);
}
@@ -126,7 +126,7 @@ static inline bool css_tryget(struct cgroup_subsys_state
*css)
extern void __css_put(struct cgroup_subsys_state *css);
static inline void css_put(struct cgroup_subsys_state *css)
{
- if (!test_bit(CSS_ROOT, >flags))
+ if (!(css->flags & CSS_ROOT))
__css_put(css);
}
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index a91e7ad..d849efd 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4020,7 +4020,7 @@ static void init_cgroup_css(struct cgroup_subsys_state
*css,
css->flags = 0;
css->id = NULL;
if (cgrp == dummytop)
- set_bit(CSS_ROOT, >flags);
+ css->flags |= CSS_ROOT;
BUG_ON(cgrp->subsys[ss->subsys_id]);
cgrp->subsys[ss->subsys_id] = css;
--
1.7.11.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 01/17] cgroup: remove incorrect dget/dput() pair in cgroup_create_dir()
cgroup_create_dir() does weird dancing with dentry refcnt. On success, it gets and then puts it achieving nothing. On failure, it puts but there isn't no matching get anywhere leading to the following oops if cgroup_create_file() fails for whatever reason. [ cut here ] kernel BUG at /work/os/work/fs/dcache.c:552! invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: CPU 2 Pid: 697, comm: mkdir Not tainted 3.7.0-rc4-work+ #3 Bochs Bochs RIP: 0010:[] [] dput+0x1dc/0x1e0 RSP: 0018:88001a3ebef8 EFLAGS: 00010246 RAX: RBX: 88000e5b1ef8 RCX: 0403 RDX: 0303 RSI: 2000 RDI: 88000e5b1f58 RBP: 88001a3ebf18 R08: 82c76960 R09: 0001 R10: 880015022080 R11: ffd9bed70f48a041 R12: ffea R13: 0001 R14: 88000e5b1f58 R15: 7fff57656d60 FS: 7ff05fcb3800() GS:88001fd0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 004046f0 CR3: 1315f000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process mkdir (pid: 697, threadinfo 88001a3ea000, task 880015022080) Stack: 88001a3ebf48 ffea 0001 88001a3ebf38 811cc889 0001 88000e5b1ef8 88001a3ebf68 811d1fc9 8800198d7f18 880019106ef8 Call Trace: [] done_path_create+0x19/0x50 [] sys_mkdirat+0x59/0x80 [] sys_mkdir+0x19/0x20 [] system_call_fastpath+0x16/0x1b Code: 00 48 8d 90 18 01 00 00 48 89 93 c0 00 00 00 4c 89 a0 18 01 00 00 48 8b 83 a0 00 00 00 83 80 28 01 00 00 01 e8 e6 6f a0 00 eb 92 <0f> 0b 66 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 49 89 fe 41 RIP [] dput+0x1dc/0x1e0 RSP ---[ end trace 1277bcfd9561ddb0 ]--- Fix it by dropping the unnecessary dget/dput() pair. Signed-off-by: Tejun Heo Cc: sta...@vger.kernel.org --- kernel/cgroup.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 0f8fa6a..d0803f0 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -2684,9 +2684,7 @@ static int cgroup_create_dir(struct cgroup *cgrp, struct dentry *dentry, dentry->d_fsdata = cgrp; inc_nlink(parent->d_inode); rcu_assign_pointer(cgrp->dentry, dentry); - dget(dentry); } - dput(dentry); return error; } -- 1.7.11.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/
