* RE: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
From: Ramesh Shanmugasundaram @ 2016-11-14 16:11 UTC (permalink / raw)
To: Hans Verkuil, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
crope-X3B1VOXEql0@public.gmane.org
Cc: Chris Paterson,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <9b772894-f6ef-d5ad-4601-735f2321ce0c-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Hi Hans,
Thanks for the review comments.
> Subject: Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
>
> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
> > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3
> SoCs.
> > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> > device represents a channel and each channel can have one or two
> > sub-channels respectively depending on the target board.
> >
> > DRIF supports only Rx functionality. It receives samples from a RF
> > frontend tuner chip it is interfaced with. The combination of DRIF and
> > the tuner device, which is registered as a sub-device, determines the
> > receive sample rate and format.
> >
> > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> > the tuner device, which can be provided by a third party vendor. DRIF
> > acts as a slave device and the tuner device acts as a master
> > transmitting the samples. The driver allows asynchronous binding of a
> > tuner device that is registered as a v4l2 sub-device. The driver can
> > learn about the tuner it is interfaced with based on port endpoint
> > properties of the device in device tree. The V4L2 SDR device inherits
> > the controls exposed by the tuner device.
> >
> > The device can also be configured to use either one or both of the
> > data pins at runtime based on the master (tuner) configuration.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > <ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
> > ---
> > .../devicetree/bindings/media/renesas,drif.txt | 136 ++
> > drivers/media/platform/Kconfig | 25 +
> > drivers/media/platform/Makefile | 1 +
> > drivers/media/platform/rcar_drif.c | 1574
> ++++++++++++++++++++
> > 4 files changed, 1736 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/media/renesas,drif.txt
> > create mode 100644 drivers/media/platform/rcar_drif.c
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > new file mode 100644
> > index 0000000..d65368a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,136 @@
> > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> > +------------------------------------------------------------
> > +
> > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master
> > +device as shown below
> > +
> > ++---------------------+ +---------------------+
> > +| |-----SCK------->|CLK |
> > +| Master |-----SS-------->|SYNC DRIFn (slave) |
> > +| |-----SD0------->|D0 |
> > +| |-----SD1------->|D1 |
> > ++---------------------+ +---------------------+
> > +
> > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 &
> drifn1).
> > +The sub-channels are like two individual channels in itself that
> > +share the common CLK & SYNC. Each sub-channel has it's own dedicated
> > +resources like irq, dma channels, address space & clock.
> > +
> > +The device tree model represents the channel and each of it's
> > +sub-channel as a separate node. The parent channel ties the
> > +sub-channels together with their phandles.
> > +
> > +Required properties of a sub-channel:
> > +-------------------------------------
> > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of
> R8A7795 SoC.
> > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible
> device.
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first
> > + followed by the generic version.
> > +- reg: offset and length of that sub-channel.
> > +- interrupts: associated with that sub-channel.
> > +- clocks: phandle and clock specifier of that sub-channel.
> > +- clock-names: clock input name string: "fck".
> > +- dmas: phandles to the DMA channel of that sub-channel.
> > +- dma-names: names of the DMA channel: "rx".
> > +
> > +Optional properties of a sub-channel:
> > +-------------------------------------
> > +- power-domains: phandle to the respective power domain.
> > +
> > +Required properties of a channel:
> > +---------------------------------
> > +- pinctrl-0: pin control group to be used for this channel.
> > +- pinctrl-names: must be "default".
> > +- sub-channels : phandles to the two sub-channels.
> > +
> > +Optional properties of a channel:
> > +---------------------------------
> > +- port: child port node of a channel that defines the local and remote
> > + endpoints. The remote endpoint is assumed to be a tuner
> subdevice
> > + endpoint.
> > +- renesas,syncmd : sync mode
> > + 0 (Frame start sync pulse mode. 1-bit width pulse
> > + indicates start of a frame)
> > + 1 (L/R sync or I2S mode) (default)
> > +- renesas,lsb-first : empty property indicates lsb bit is received
> first.
> > + When not defined msb bit is received first (default)
> > +- renesas,syncac-pol-high : empty property indicates sync signal
> polarity.
> > + When defined, active high or high->low sync signal.
> > + When not defined, active low or low->high sync signal
> > + (default)
> > +- renesas,dtdl : delay between sync signal and start of
> reception.
> > + Must contain one of the following values:
> > + 0 (no bit delay)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay) (default)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
> > +- renesas,syncdl : delay between end of reception and sync signal
> edge.
> > + Must contain one of the following values:
> > + 0 (no bit delay) (default)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
> > + 300 (3-clock-cycle delay)
> > +
> > +Example
> > +--------
> > +
> > +SoC common dtsi file
> > +
> > + drif00: rif@e6f40000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f40000 0 0x64>;
> > + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 515>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
> > + dma-names = "rx", "rx";
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif01: rif@e6f50000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f50000 0 0x64>;
> > + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 514>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
> > + dma-names = "rx", "rx";
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif0: rif@0 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + sub-channels = <&drif00>, <&drif01>;
> > + status = "disabled";
> > + };
> > +
> > +Board specific dts file
> > +
> > +&drif00 {
> > + status = "okay";
> > +};
> > +
> > +&drif01 {
> > + status = "okay";
> > +};
> > +
> > +&drif0 {
> > + pinctrl-0 = <&drif0_pins>;
> > + pinctrl-names = "default";
> > + renesas,syncac-pol-high;
> > + status = "okay";
> > + port {
> > + drif0_ep: endpoint {
> > + remote-endpoint = <&tuner_subdev_ep>;
> > + };
> > + };
> > +};
> > diff --git a/drivers/media/platform/Kconfig
> > b/drivers/media/platform/Kconfig index 754edbf1..0ae83a8 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -393,3 +393,28 @@ menuconfig DVB_PLATFORM_DRIVERS if
> > DVB_PLATFORM_DRIVERS source
> > "drivers/media/platform/sti/c8sectpfe/Kconfig"
> > endif #DVB_PLATFORM_DRIVERS
> > +
> > +menuconfig SDR_PLATFORM_DRIVERS
> > + bool "SDR platform devices"
> > + depends on MEDIA_SDR_SUPPORT
> > + default n
> > + ---help---
> > + Say Y here to enable support for platform-specific SDR Drivers.
> > +
> > +if SDR_PLATFORM_DRIVERS
> > +
> > +config VIDEO_RCAR_DRIF
> > + tristate "Renesas Digitial Radio Interface (DRIF)"
> > + depends on VIDEO_V4L2 && HAS_DMA
> > + depends on ARCH_RENESAS
> > + select VIDEOBUF2_VMALLOC
> > + ---help---
> > + Say Y if you want to enable R-Car Gen3 DRIF support. DRIF is
> Digital
> > + Radio Interface that interfaces with an RF front end chip. It is a
> > + receiver of digital data which uses DMA to transfer received data
> to
> > + a configured location for an application to use.
> > +
> > + To compile this driver as a module, choose M here; the module
> > + will be called rcar_drif.
> > +
> > +endif # SDR_PLATFORM_DRIVERS
> > diff --git a/drivers/media/platform/Makefile
> > b/drivers/media/platform/Makefile index f842933..49ce238 100644
> > --- a/drivers/media/platform/Makefile
> > +++ b/drivers/media/platform/Makefile
> > @@ -49,6 +49,7 @@ obj-$(CONFIG_SOC_CAMERA) += soc_camera/
> >
> > obj-$(CONFIG_VIDEO_RENESAS_FCP) += rcar-fcp.o
> > obj-$(CONFIG_VIDEO_RENESAS_JPU) += rcar_jpu.o
> > +obj-$(CONFIG_VIDEO_RCAR_DRIF) += rcar_drif.o
> > obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/
> >
> > obj-y += omap/
> > diff --git a/drivers/media/platform/rcar_drif.c
> > b/drivers/media/platform/rcar_drif.c
> > new file mode 100644
> > index 0000000..34dc282
> > --- /dev/null
> > +++ b/drivers/media/platform/rcar_drif.c
> > @@ -0,0 +1,1574 @@
>
> <snip>
>
> +#define for_each_rcar_drif_subdev(sd, tmp, ch) \
> + list_for_each_entry_safe(sd, tmp, &ch->v4l2_dev.subdevs, list)
> +
>
> Please don't use this. media/v4l2-device.h has a bunch of similar
> functions for this. Use those instead.
Thanks. Agreed.
>
> <snip>
>
> > +static int rcar_drif_querycap(struct file *file, void *fh,
> > + struct v4l2_capability *cap) {
> > + struct rcar_drif_chan *ch = video_drvdata(file);
> > +
> > + strlcpy(cap->driver, KBUILD_MODNAME, sizeof(cap->driver));
> > + strlcpy(cap->card, ch->vdev.name, sizeof(cap->card));
> > + cap->device_caps = V4L2_CAP_SDR_CAPTURE | V4L2_CAP_TUNER |
> > + V4L2_CAP_STREAMING | V4L2_CAP_READWRITE;
> > + cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
>
> Set device_caps in struct video_device and drop it here.
>
> The core will fill in cap->device_caps and cap->capabilities for you.
Agreed.
>
> > + snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
> > + ch->vdev.name);
> > + return 0;
> > +}
> > +
> > +static int rcar_drif_set_default_format(struct rcar_drif_chan *ch) {
> > + unsigned int i;
> > +
> > + for (i = 0; i < NUM_FORMATS; i++) {
> > + /* Find any matching fmt and set it as default */
> > + if (ch->num_hw_schans == formats[i].num_schans) {
> > + ch->fmt_idx = i;
> > + ch->cur_schans_mask = ch->hw_schans_mask;
> > + ch->num_cur_schans = ch->num_hw_schans;
> > + dev_dbg(ch->dev, "default fmt[%u]: mask %lu num %u\n",
> > + i, ch->cur_schans_mask, ch->num_cur_schans);
> > + return 0;
> > + }
> > + }
> > + dev_err(ch->dev, "no matching sdr fmt found\n");
> > + return -EINVAL;
> > +}
> > +
> > +static int rcar_drif_enum_fmt_sdr_cap(struct file *file, void *priv,
> > + struct v4l2_fmtdesc *f)
> > +{
> > + if (f->index >= NUM_FORMATS)
> > + return -EINVAL;
> > +
> > + strlcpy(f->description, formats[f->index].name,
> > +sizeof(f->description));
>
> Drop this. The core fills that in for you.
>
Agreed.
> > + f->pixelformat = formats[f->index].pixelformat;
> > + return 0;
> > +}
> > +
> > +static int rcar_drif_g_fmt_sdr_cap(struct file *file, void *priv,
> > + struct v4l2_format *f)
> > +{
> > + struct rcar_drif_chan *ch = video_drvdata(file);
> > +
> > + f->fmt.sdr.pixelformat = formats[ch->fmt_idx].pixelformat;
> > + f->fmt.sdr.buffersize = formats[ch->fmt_idx].buffersize;
> > + memset(f->fmt.sdr.reserved, 0, sizeof(f->fmt.sdr.reserved));
> > + return 0;
> > +}
> > +
[snip]
> > +/* Parse sub-devs (tuner) to find a matching device */ static int
> > +rcar_drif_parse_subdevs(struct device *dev,
> > + struct v4l2_async_notifier *notifier) {
> > + struct device_node *node = NULL;
> > +
> > + notifier->subdevs = devm_kzalloc(dev, sizeof(*notifier->subdevs),
> > + GFP_KERNEL);
> > + if (!notifier->subdevs)
> > + return -ENOMEM;
> > +
> > + node = of_graph_get_next_endpoint(dev->of_node, node);
>
> Do:
>
> if (!node)
> return 0;
>
> And the remainder can be shifted one tab to the left.
Agreed.
>
> > + if (node) {
> > + struct rcar_drif_async_subdev *rsd;
> > +
> > + rsd = devm_kzalloc(dev, sizeof(*rsd), GFP_KERNEL);
> > + if (!rsd) {
> > + of_node_put(node);
> > + return -ENOMEM;
> > + }
> > +
> > + notifier->subdevs[notifier->num_subdevs] = &rsd->asd;
> > + rsd->asd.match.of.node =
> of_graph_get_remote_port_parent(node);
> > + of_node_put(node);
> > + if (!rsd->asd.match.of.node) {
> > + dev_warn(dev, "bad remote port parent\n");
> > + return -EINVAL;
> > + }
> > +
> > + rsd->asd.match_type = V4L2_ASYNC_MATCH_OF;
> > + notifier->num_subdevs++;
> > + }
> > + return 0;
> > +}
> > +
> > +/* SIRMDR1 configuration */
> > +static int rcar_drif_validate_syncmd(struct rcar_drif_chan *ch, u32
> > +val) {
> > + if (val > 1) {
> > + dev_err(ch->dev, "invalid syncmd %u using L/R mode\n", val);
> > + return -EINVAL;
> > + }
> > +
> > + ch->mdr1 &= ~(3 << 28); /* Clear current settings */
> > + if (val == 0)
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_SYNCMD_FRAME;
> > + else
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_SYNCMD_LR;
> > + return 0;
> > +}
> > +
> > +/* Get the dtdl or syncdl bits as in MSIOF */ static u32
> > +rcar_drif_get_dtdl_or_syncdl_bits(u32 dtdl_or_syncdl) {
> > + /*
> > + * DTDL/SYNCDL bit : dtdl/syncdl
> > + * b'000 : 0
> > + * b'001 : 100
> > + * b'010 : 200
> > + * b'011 (SYNCDL only) : 300
> > + * b'101 : 50
> > + * b'110 : 150
> > + */
> > + if (dtdl_or_syncdl % 100)
> > + return dtdl_or_syncdl / 100 + 5;
> > + else
>
> Line can be dropped.
Agreed.
>
> > + return dtdl_or_syncdl / 100;
> > +}
> > +
> > +static int rcar_drif_validate_dtdl_syncdl(struct rcar_drif_chan *ch)
> > +{
> > + struct device_node *np = ch->dev->of_node;
> > + u32 dtdl = 100, syncdl = 0;
> > +
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_DTDL_1 | RCAR_DRIF_SIRMDR1_SYNCDL_0;
> > + of_property_read_u32(np, "renesas,dtdl", &dtdl);
> > + of_property_read_u32(np, "renesas,syncdl", &syncdl);
> > +
> > + /* Sanity checks */
> > + if (dtdl > 200 || syncdl > 300) {
> > + dev_err(ch->dev, "invalid dtdl %u/syncdl %u\n", dtdl, syncdl);
> > + return -EINVAL;
> > + }
> > + if ((dtdl + syncdl) % 100) {
> > + dev_err(ch->dev, "sum of dtdl %u & syncdl %u not OK\n",
> > + dtdl, syncdl);
> > + return -EINVAL;
> > + }
> > + ch->mdr1 &= ~(7 << 20) & ~(7 << 16); /* Clear current settings
> */
> > + ch->mdr1 |= rcar_drif_get_dtdl_or_syncdl_bits(dtdl) << 20;
> > + ch->mdr1 |= rcar_drif_get_dtdl_or_syncdl_bits(syncdl) << 16;
> > + return 0;
> > +}
> > +
> > +static int rcar_drif_parse_properties(struct rcar_drif_chan *ch) {
> > + struct device_node *np = ch->dev->of_node;
> > + u32 syncmd;
> > + int ret;
> > +
> > + /* Set the defaults and check for overrides */
> > + ch->mdr1 = RCAR_DRIF_SIRMDR1_SYNCMD_LR;
> > + if (!of_property_read_u32(np, "renesas,syncmd", &syncmd)) {
> > + ret = rcar_drif_validate_syncmd(ch, syncmd);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + if (of_find_property(np, "renesas,lsb-first", NULL))
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_LSB_FIRST;
> > + else
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_MSB_FIRST;
> > +
> > + if (of_find_property(np, "renesas,syncac-pol-high", NULL))
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_SYNCAC_POL_HIGH;
> > + else
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_SYNCAC_POL_LOW;
> > +
> > + return rcar_drif_validate_dtdl_syncdl(ch);
> > +}
> > +
> > +static u32 rcar_drif_enum_sub_channels(struct platform_device *pdev,
> > + struct platform_device *s_pdev[]) {
> > + struct device_node *s_np;
> > + u32 hw_schans_mask = 0;
> > + unsigned int i;
> > +
> > + for (i = 0; i < RCAR_DRIF_MAX_SUBCHANS; i++) {
> > + s_np = of_parse_phandle(pdev->dev.of_node, "sub-channels", i);
> > + if (s_np && of_device_is_available(s_np)) {
> > + s_pdev[i] = of_find_device_by_node(s_np);
> > + if (s_pdev[i]) {
> > + hw_schans_mask |= BIT(i);
> > + dev_dbg(&s_pdev[i]->dev, "schan%u ok\n", i);
> > + }
> > + }
> > + }
> > + return hw_schans_mask;
> > +}
> > +
> > +static int rcar_drif_probe(struct platform_device *pdev) {
> > + struct platform_device *s_pdev[RCAR_DRIF_MAX_SUBCHANS];
> > + unsigned long hw_schans_mask;
> > + struct rcar_drif_chan *ch;
> > + unsigned int i;
> > + int ret;
> > +
> > + /*
> > + * Sub-channel resources are managed by the parent channel instance.
> > + * The sub-channel instance helps only in registering with power
> domain
> > + * to aid in run-time pm support
> > + */
> > + if (!of_find_property(pdev->dev.of_node, "sub-channels", NULL))
> > + return 0;
> > +
> > + /* Parent channel instance */
> > + hw_schans_mask = rcar_drif_enum_sub_channels(pdev, s_pdev);
> > + if (!hw_schans_mask) {
> > + dev_err(&pdev->dev, "no sub-channels enabled\n");
> > + return -ENODEV;
> > + }
> > +
> > +
> > + /* Reserve memory for driver structure */
> > + ch = devm_kzalloc(&pdev->dev, sizeof(*ch), GFP_KERNEL);
> > + if (!ch) {
> > + ret = PTR_ERR(ch);
> > + dev_err(&pdev->dev, "failed alloc drif context\n");
> > + return ret;
> > + }
> > + ch->dev = &pdev->dev;
> > +
> > + /* Parse device tree optional properties */
> > + ret = rcar_drif_parse_properties(ch);
> > + if (ret)
> > + return ret;
> > +
> > + dev_dbg(ch->dev, "parsed mdr1 0x%08x\n", ch->mdr1);
> > +
> > + /* Setup enabled sub-channels */
> > + for_each_rcar_drif_subchannel(i, &hw_schans_mask) {
> > + struct clk *clkp;
> > + struct resource *res;
> > + void __iomem *base;
> > +
> > + /* Peripheral clock */
> > + clkp = devm_clk_get(&s_pdev[i]->dev, "fck");
> > + if (IS_ERR(clkp)) {
> > + ret = PTR_ERR(clkp);
> > + dev_err(&s_pdev[i]->dev, "clk get failed (%d)\n", ret);
> > + return ret;
> > + }
> > +
> > + /* Register map */
> > + res = platform_get_resource(s_pdev[i], IORESOURCE_MEM, 0);
> > + base = devm_ioremap_resource(&s_pdev[i]->dev, res);
> > + if (IS_ERR(base)) {
> > + ret = PTR_ERR(base);
> > + dev_err(&s_pdev[i]->dev, "ioremap failed (%d)\n", ret);
> > + return ret;
> > + }
> > +
> > + /* Reserve memory for enabled sub-channel */
> > + ch->sch[i] = devm_kzalloc(&pdev->dev, sizeof(*ch->sch[i]),
> > + GFP_KERNEL);
> > + if (!ch->sch[i]) {
> > + ret = PTR_ERR(ch);
> > + dev_err(&s_pdev[i]->dev, "failed alloc sub-channel\n");
> > + return ret;
> > + }
> > + ch->sch[i]->pdev = s_pdev[i];
> > + ch->sch[i]->clkp = clkp;
> > + ch->sch[i]->base = base;
> > + ch->sch[i]->num = i;
> > + ch->sch[i]->start = res->start;
> > + ch->sch[i]->parent = ch;
> > + ch->num_hw_schans++;
> > + }
> > + ch->hw_schans_mask = hw_schans_mask;
> > +
> > + /* Validate any supported format for enabled sub-channels */
> > + ret = rcar_drif_set_default_format(ch);
> > + if (ret)
> > + return ret;
> > +
> > + /* Set defaults */
> > + ch->num_hwbufs = RCAR_DRIF_DEFAULT_NUM_HWBUFS;
> > + ch->hwbuf_size = RCAR_DRIF_DEFAULT_HWBUF_SIZE;
> > +
> > + mutex_init(&ch->v4l2_mutex);
> > + mutex_init(&ch->vb_queue_mutex);
> > + spin_lock_init(&ch->queued_bufs_lock);
> > + INIT_LIST_HEAD(&ch->queued_bufs);
> > +
> > + /* Init videobuf2 queue structure */
> > + ch->vb_queue.type = V4L2_BUF_TYPE_SDR_CAPTURE;
> > + ch->vb_queue.io_modes = VB2_READ | VB2_MMAP | VB2_DMABUF;
> > + ch->vb_queue.drv_priv = ch;
> > + ch->vb_queue.buf_struct_size = sizeof(struct rcar_drif_frame_buf);
> > + ch->vb_queue.ops = &rcar_drif_vb2_ops;
> > + ch->vb_queue.mem_ops = &vb2_vmalloc_memops;
> > + ch->vb_queue.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> > +
> > + /* Init videobuf2 queue */
> > + ret = vb2_queue_init(&ch->vb_queue);
> > + if (ret) {
> > + dev_err(ch->dev, "could not initialize vb2 queue\n");
> > + return ret;
> > + }
> > +
> > + /* Init video_device structure */
> > + ch->vdev = rcar_drif_vdev;
>
> Don't embed video_device, use video_device_alloc instead. A lot of drivers
> embed this, but it turns out not to be a good idea. So new drivers should
> use video_device_alloc.
Agreed.
Thanks,
Ramesh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
From: Ramesh Shanmugasundaram @ 2016-11-14 16:11 UTC (permalink / raw)
To: Hans Verkuil, robh+dt@kernel.org, mark.rutland@arm.com,
mchehab@kernel.org, sakari.ailus@linux.intel.com, crope@iki.fi
Cc: Chris Paterson, laurent.pinchart@ideasonboard.com,
geert+renesas@glider.be, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <9b772894-f6ef-d5ad-4601-735f2321ce0c@xs4all.nl>
Hi Hans,
Thanks for the review comments.
> Subject: Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
>
> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
> > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3
> SoCs.
> > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> > device represents a channel and each channel can have one or two
> > sub-channels respectively depending on the target board.
> >
> > DRIF supports only Rx functionality. It receives samples from a RF
> > frontend tuner chip it is interfaced with. The combination of DRIF and
> > the tuner device, which is registered as a sub-device, determines the
> > receive sample rate and format.
> >
> > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> > the tuner device, which can be provided by a third party vendor. DRIF
> > acts as a slave device and the tuner device acts as a master
> > transmitting the samples. The driver allows asynchronous binding of a
> > tuner device that is registered as a v4l2 sub-device. The driver can
> > learn about the tuner it is interfaced with based on port endpoint
> > properties of the device in device tree. The V4L2 SDR device inherits
> > the controls exposed by the tuner device.
> >
> > The device can also be configured to use either one or both of the
> > data pins at runtime based on the master (tuner) configuration.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > <ramesh.shanmugasundaram@bp.renesas.com>
> > ---
> > .../devicetree/bindings/media/renesas,drif.txt | 136 ++
> > drivers/media/platform/Kconfig | 25 +
> > drivers/media/platform/Makefile | 1 +
> > drivers/media/platform/rcar_drif.c | 1574
> ++++++++++++++++++++
> > 4 files changed, 1736 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/media/renesas,drif.txt
> > create mode 100644 drivers/media/platform/rcar_drif.c
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > new file mode 100644
> > index 0000000..d65368a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,136 @@
> > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> > +------------------------------------------------------------
> > +
> > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master
> > +device as shown below
> > +
> > ++---------------------+ +---------------------+
> > +| |-----SCK------->|CLK |
> > +| Master |-----SS-------->|SYNC DRIFn (slave) |
> > +| |-----SD0------->|D0 |
> > +| |-----SD1------->|D1 |
> > ++---------------------+ +---------------------+
> > +
> > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 &
> drifn1).
> > +The sub-channels are like two individual channels in itself that
> > +share the common CLK & SYNC. Each sub-channel has it's own dedicated
> > +resources like irq, dma channels, address space & clock.
> > +
> > +The device tree model represents the channel and each of it's
> > +sub-channel as a separate node. The parent channel ties the
> > +sub-channels together with their phandles.
> > +
> > +Required properties of a sub-channel:
> > +-------------------------------------
> > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of
> R8A7795 SoC.
> > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible
> device.
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first
> > + followed by the generic version.
> > +- reg: offset and length of that sub-channel.
> > +- interrupts: associated with that sub-channel.
> > +- clocks: phandle and clock specifier of that sub-channel.
> > +- clock-names: clock input name string: "fck".
> > +- dmas: phandles to the DMA channel of that sub-channel.
> > +- dma-names: names of the DMA channel: "rx".
> > +
> > +Optional properties of a sub-channel:
> > +-------------------------------------
> > +- power-domains: phandle to the respective power domain.
> > +
> > +Required properties of a channel:
> > +---------------------------------
> > +- pinctrl-0: pin control group to be used for this channel.
> > +- pinctrl-names: must be "default".
> > +- sub-channels : phandles to the two sub-channels.
> > +
> > +Optional properties of a channel:
> > +---------------------------------
> > +- port: child port node of a channel that defines the local and remote
> > + endpoints. The remote endpoint is assumed to be a tuner
> subdevice
> > + endpoint.
> > +- renesas,syncmd : sync mode
> > + 0 (Frame start sync pulse mode. 1-bit width pulse
> > + indicates start of a frame)
> > + 1 (L/R sync or I2S mode) (default)
> > +- renesas,lsb-first : empty property indicates lsb bit is received
> first.
> > + When not defined msb bit is received first (default)
> > +- renesas,syncac-pol-high : empty property indicates sync signal
> polarity.
> > + When defined, active high or high->low sync signal.
> > + When not defined, active low or low->high sync signal
> > + (default)
> > +- renesas,dtdl : delay between sync signal and start of
> reception.
> > + Must contain one of the following values:
> > + 0 (no bit delay)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay) (default)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
> > +- renesas,syncdl : delay between end of reception and sync signal
> edge.
> > + Must contain one of the following values:
> > + 0 (no bit delay) (default)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
> > + 300 (3-clock-cycle delay)
> > +
> > +Example
> > +--------
> > +
> > +SoC common dtsi file
> > +
> > + drif00: rif@e6f40000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f40000 0 0x64>;
> > + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 515>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
> > + dma-names = "rx", "rx";
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif01: rif@e6f50000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f50000 0 0x64>;
> > + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 514>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
> > + dma-names = "rx", "rx";
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif0: rif@0 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + sub-channels = <&drif00>, <&drif01>;
> > + status = "disabled";
> > + };
> > +
> > +Board specific dts file
> > +
> > +&drif00 {
> > + status = "okay";
> > +};
> > +
> > +&drif01 {
> > + status = "okay";
> > +};
> > +
> > +&drif0 {
> > + pinctrl-0 = <&drif0_pins>;
> > + pinctrl-names = "default";
> > + renesas,syncac-pol-high;
> > + status = "okay";
> > + port {
> > + drif0_ep: endpoint {
> > + remote-endpoint = <&tuner_subdev_ep>;
> > + };
> > + };
> > +};
> > diff --git a/drivers/media/platform/Kconfig
> > b/drivers/media/platform/Kconfig index 754edbf1..0ae83a8 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -393,3 +393,28 @@ menuconfig DVB_PLATFORM_DRIVERS if
> > DVB_PLATFORM_DRIVERS source
> > "drivers/media/platform/sti/c8sectpfe/Kconfig"
> > endif #DVB_PLATFORM_DRIVERS
> > +
> > +menuconfig SDR_PLATFORM_DRIVERS
> > + bool "SDR platform devices"
> > + depends on MEDIA_SDR_SUPPORT
> > + default n
> > + ---help---
> > + Say Y here to enable support for platform-specific SDR Drivers.
> > +
> > +if SDR_PLATFORM_DRIVERS
> > +
> > +config VIDEO_RCAR_DRIF
> > + tristate "Renesas Digitial Radio Interface (DRIF)"
> > + depends on VIDEO_V4L2 && HAS_DMA
> > + depends on ARCH_RENESAS
> > + select VIDEOBUF2_VMALLOC
> > + ---help---
> > + Say Y if you want to enable R-Car Gen3 DRIF support. DRIF is
> Digital
> > + Radio Interface that interfaces with an RF front end chip. It is a
> > + receiver of digital data which uses DMA to transfer received data
> to
> > + a configured location for an application to use.
> > +
> > + To compile this driver as a module, choose M here; the module
> > + will be called rcar_drif.
> > +
> > +endif # SDR_PLATFORM_DRIVERS
> > diff --git a/drivers/media/platform/Makefile
> > b/drivers/media/platform/Makefile index f842933..49ce238 100644
> > --- a/drivers/media/platform/Makefile
> > +++ b/drivers/media/platform/Makefile
> > @@ -49,6 +49,7 @@ obj-$(CONFIG_SOC_CAMERA) += soc_camera/
> >
> > obj-$(CONFIG_VIDEO_RENESAS_FCP) += rcar-fcp.o
> > obj-$(CONFIG_VIDEO_RENESAS_JPU) += rcar_jpu.o
> > +obj-$(CONFIG_VIDEO_RCAR_DRIF) += rcar_drif.o
> > obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/
> >
> > obj-y += omap/
> > diff --git a/drivers/media/platform/rcar_drif.c
> > b/drivers/media/platform/rcar_drif.c
> > new file mode 100644
> > index 0000000..34dc282
> > --- /dev/null
> > +++ b/drivers/media/platform/rcar_drif.c
> > @@ -0,0 +1,1574 @@
>
> <snip>
>
> +#define for_each_rcar_drif_subdev(sd, tmp, ch) \
> + list_for_each_entry_safe(sd, tmp, &ch->v4l2_dev.subdevs, list)
> +
>
> Please don't use this. media/v4l2-device.h has a bunch of similar
> functions for this. Use those instead.
Thanks. Agreed.
>
> <snip>
>
> > +static int rcar_drif_querycap(struct file *file, void *fh,
> > + struct v4l2_capability *cap) {
> > + struct rcar_drif_chan *ch = video_drvdata(file);
> > +
> > + strlcpy(cap->driver, KBUILD_MODNAME, sizeof(cap->driver));
> > + strlcpy(cap->card, ch->vdev.name, sizeof(cap->card));
> > + cap->device_caps = V4L2_CAP_SDR_CAPTURE | V4L2_CAP_TUNER |
> > + V4L2_CAP_STREAMING | V4L2_CAP_READWRITE;
> > + cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
>
> Set device_caps in struct video_device and drop it here.
>
> The core will fill in cap->device_caps and cap->capabilities for you.
Agreed.
>
> > + snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
> > + ch->vdev.name);
> > + return 0;
> > +}
> > +
> > +static int rcar_drif_set_default_format(struct rcar_drif_chan *ch) {
> > + unsigned int i;
> > +
> > + for (i = 0; i < NUM_FORMATS; i++) {
> > + /* Find any matching fmt and set it as default */
> > + if (ch->num_hw_schans == formats[i].num_schans) {
> > + ch->fmt_idx = i;
> > + ch->cur_schans_mask = ch->hw_schans_mask;
> > + ch->num_cur_schans = ch->num_hw_schans;
> > + dev_dbg(ch->dev, "default fmt[%u]: mask %lu num %u\n",
> > + i, ch->cur_schans_mask, ch->num_cur_schans);
> > + return 0;
> > + }
> > + }
> > + dev_err(ch->dev, "no matching sdr fmt found\n");
> > + return -EINVAL;
> > +}
> > +
> > +static int rcar_drif_enum_fmt_sdr_cap(struct file *file, void *priv,
> > + struct v4l2_fmtdesc *f)
> > +{
> > + if (f->index >= NUM_FORMATS)
> > + return -EINVAL;
> > +
> > + strlcpy(f->description, formats[f->index].name,
> > +sizeof(f->description));
>
> Drop this. The core fills that in for you.
>
Agreed.
> > + f->pixelformat = formats[f->index].pixelformat;
> > + return 0;
> > +}
> > +
> > +static int rcar_drif_g_fmt_sdr_cap(struct file *file, void *priv,
> > + struct v4l2_format *f)
> > +{
> > + struct rcar_drif_chan *ch = video_drvdata(file);
> > +
> > + f->fmt.sdr.pixelformat = formats[ch->fmt_idx].pixelformat;
> > + f->fmt.sdr.buffersize = formats[ch->fmt_idx].buffersize;
> > + memset(f->fmt.sdr.reserved, 0, sizeof(f->fmt.sdr.reserved));
> > + return 0;
> > +}
> > +
[snip]
> > +/* Parse sub-devs (tuner) to find a matching device */ static int
> > +rcar_drif_parse_subdevs(struct device *dev,
> > + struct v4l2_async_notifier *notifier) {
> > + struct device_node *node = NULL;
> > +
> > + notifier->subdevs = devm_kzalloc(dev, sizeof(*notifier->subdevs),
> > + GFP_KERNEL);
> > + if (!notifier->subdevs)
> > + return -ENOMEM;
> > +
> > + node = of_graph_get_next_endpoint(dev->of_node, node);
>
> Do:
>
> if (!node)
> return 0;
>
> And the remainder can be shifted one tab to the left.
Agreed.
>
> > + if (node) {
> > + struct rcar_drif_async_subdev *rsd;
> > +
> > + rsd = devm_kzalloc(dev, sizeof(*rsd), GFP_KERNEL);
> > + if (!rsd) {
> > + of_node_put(node);
> > + return -ENOMEM;
> > + }
> > +
> > + notifier->subdevs[notifier->num_subdevs] = &rsd->asd;
> > + rsd->asd.match.of.node =
> of_graph_get_remote_port_parent(node);
> > + of_node_put(node);
> > + if (!rsd->asd.match.of.node) {
> > + dev_warn(dev, "bad remote port parent\n");
> > + return -EINVAL;
> > + }
> > +
> > + rsd->asd.match_type = V4L2_ASYNC_MATCH_OF;
> > + notifier->num_subdevs++;
> > + }
> > + return 0;
> > +}
> > +
> > +/* SIRMDR1 configuration */
> > +static int rcar_drif_validate_syncmd(struct rcar_drif_chan *ch, u32
> > +val) {
> > + if (val > 1) {
> > + dev_err(ch->dev, "invalid syncmd %u using L/R mode\n", val);
> > + return -EINVAL;
> > + }
> > +
> > + ch->mdr1 &= ~(3 << 28); /* Clear current settings */
> > + if (val == 0)
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_SYNCMD_FRAME;
> > + else
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_SYNCMD_LR;
> > + return 0;
> > +}
> > +
> > +/* Get the dtdl or syncdl bits as in MSIOF */ static u32
> > +rcar_drif_get_dtdl_or_syncdl_bits(u32 dtdl_or_syncdl) {
> > + /*
> > + * DTDL/SYNCDL bit : dtdl/syncdl
> > + * b'000 : 0
> > + * b'001 : 100
> > + * b'010 : 200
> > + * b'011 (SYNCDL only) : 300
> > + * b'101 : 50
> > + * b'110 : 150
> > + */
> > + if (dtdl_or_syncdl % 100)
> > + return dtdl_or_syncdl / 100 + 5;
> > + else
>
> Line can be dropped.
Agreed.
>
> > + return dtdl_or_syncdl / 100;
> > +}
> > +
> > +static int rcar_drif_validate_dtdl_syncdl(struct rcar_drif_chan *ch)
> > +{
> > + struct device_node *np = ch->dev->of_node;
> > + u32 dtdl = 100, syncdl = 0;
> > +
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_DTDL_1 | RCAR_DRIF_SIRMDR1_SYNCDL_0;
> > + of_property_read_u32(np, "renesas,dtdl", &dtdl);
> > + of_property_read_u32(np, "renesas,syncdl", &syncdl);
> > +
> > + /* Sanity checks */
> > + if (dtdl > 200 || syncdl > 300) {
> > + dev_err(ch->dev, "invalid dtdl %u/syncdl %u\n", dtdl, syncdl);
> > + return -EINVAL;
> > + }
> > + if ((dtdl + syncdl) % 100) {
> > + dev_err(ch->dev, "sum of dtdl %u & syncdl %u not OK\n",
> > + dtdl, syncdl);
> > + return -EINVAL;
> > + }
> > + ch->mdr1 &= ~(7 << 20) & ~(7 << 16); /* Clear current settings
> */
> > + ch->mdr1 |= rcar_drif_get_dtdl_or_syncdl_bits(dtdl) << 20;
> > + ch->mdr1 |= rcar_drif_get_dtdl_or_syncdl_bits(syncdl) << 16;
> > + return 0;
> > +}
> > +
> > +static int rcar_drif_parse_properties(struct rcar_drif_chan *ch) {
> > + struct device_node *np = ch->dev->of_node;
> > + u32 syncmd;
> > + int ret;
> > +
> > + /* Set the defaults and check for overrides */
> > + ch->mdr1 = RCAR_DRIF_SIRMDR1_SYNCMD_LR;
> > + if (!of_property_read_u32(np, "renesas,syncmd", &syncmd)) {
> > + ret = rcar_drif_validate_syncmd(ch, syncmd);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + if (of_find_property(np, "renesas,lsb-first", NULL))
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_LSB_FIRST;
> > + else
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_MSB_FIRST;
> > +
> > + if (of_find_property(np, "renesas,syncac-pol-high", NULL))
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_SYNCAC_POL_HIGH;
> > + else
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_SYNCAC_POL_LOW;
> > +
> > + return rcar_drif_validate_dtdl_syncdl(ch);
> > +}
> > +
> > +static u32 rcar_drif_enum_sub_channels(struct platform_device *pdev,
> > + struct platform_device *s_pdev[]) {
> > + struct device_node *s_np;
> > + u32 hw_schans_mask = 0;
> > + unsigned int i;
> > +
> > + for (i = 0; i < RCAR_DRIF_MAX_SUBCHANS; i++) {
> > + s_np = of_parse_phandle(pdev->dev.of_node, "sub-channels", i);
> > + if (s_np && of_device_is_available(s_np)) {
> > + s_pdev[i] = of_find_device_by_node(s_np);
> > + if (s_pdev[i]) {
> > + hw_schans_mask |= BIT(i);
> > + dev_dbg(&s_pdev[i]->dev, "schan%u ok\n", i);
> > + }
> > + }
> > + }
> > + return hw_schans_mask;
> > +}
> > +
> > +static int rcar_drif_probe(struct platform_device *pdev) {
> > + struct platform_device *s_pdev[RCAR_DRIF_MAX_SUBCHANS];
> > + unsigned long hw_schans_mask;
> > + struct rcar_drif_chan *ch;
> > + unsigned int i;
> > + int ret;
> > +
> > + /*
> > + * Sub-channel resources are managed by the parent channel instance.
> > + * The sub-channel instance helps only in registering with power
> domain
> > + * to aid in run-time pm support
> > + */
> > + if (!of_find_property(pdev->dev.of_node, "sub-channels", NULL))
> > + return 0;
> > +
> > + /* Parent channel instance */
> > + hw_schans_mask = rcar_drif_enum_sub_channels(pdev, s_pdev);
> > + if (!hw_schans_mask) {
> > + dev_err(&pdev->dev, "no sub-channels enabled\n");
> > + return -ENODEV;
> > + }
> > +
> > +
> > + /* Reserve memory for driver structure */
> > + ch = devm_kzalloc(&pdev->dev, sizeof(*ch), GFP_KERNEL);
> > + if (!ch) {
> > + ret = PTR_ERR(ch);
> > + dev_err(&pdev->dev, "failed alloc drif context\n");
> > + return ret;
> > + }
> > + ch->dev = &pdev->dev;
> > +
> > + /* Parse device tree optional properties */
> > + ret = rcar_drif_parse_properties(ch);
> > + if (ret)
> > + return ret;
> > +
> > + dev_dbg(ch->dev, "parsed mdr1 0x%08x\n", ch->mdr1);
> > +
> > + /* Setup enabled sub-channels */
> > + for_each_rcar_drif_subchannel(i, &hw_schans_mask) {
> > + struct clk *clkp;
> > + struct resource *res;
> > + void __iomem *base;
> > +
> > + /* Peripheral clock */
> > + clkp = devm_clk_get(&s_pdev[i]->dev, "fck");
> > + if (IS_ERR(clkp)) {
> > + ret = PTR_ERR(clkp);
> > + dev_err(&s_pdev[i]->dev, "clk get failed (%d)\n", ret);
> > + return ret;
> > + }
> > +
> > + /* Register map */
> > + res = platform_get_resource(s_pdev[i], IORESOURCE_MEM, 0);
> > + base = devm_ioremap_resource(&s_pdev[i]->dev, res);
> > + if (IS_ERR(base)) {
> > + ret = PTR_ERR(base);
> > + dev_err(&s_pdev[i]->dev, "ioremap failed (%d)\n", ret);
> > + return ret;
> > + }
> > +
> > + /* Reserve memory for enabled sub-channel */
> > + ch->sch[i] = devm_kzalloc(&pdev->dev, sizeof(*ch->sch[i]),
> > + GFP_KERNEL);
> > + if (!ch->sch[i]) {
> > + ret = PTR_ERR(ch);
> > + dev_err(&s_pdev[i]->dev, "failed alloc sub-channel\n");
> > + return ret;
> > + }
> > + ch->sch[i]->pdev = s_pdev[i];
> > + ch->sch[i]->clkp = clkp;
> > + ch->sch[i]->base = base;
> > + ch->sch[i]->num = i;
> > + ch->sch[i]->start = res->start;
> > + ch->sch[i]->parent = ch;
> > + ch->num_hw_schans++;
> > + }
> > + ch->hw_schans_mask = hw_schans_mask;
> > +
> > + /* Validate any supported format for enabled sub-channels */
> > + ret = rcar_drif_set_default_format(ch);
> > + if (ret)
> > + return ret;
> > +
> > + /* Set defaults */
> > + ch->num_hwbufs = RCAR_DRIF_DEFAULT_NUM_HWBUFS;
> > + ch->hwbuf_size = RCAR_DRIF_DEFAULT_HWBUF_SIZE;
> > +
> > + mutex_init(&ch->v4l2_mutex);
> > + mutex_init(&ch->vb_queue_mutex);
> > + spin_lock_init(&ch->queued_bufs_lock);
> > + INIT_LIST_HEAD(&ch->queued_bufs);
> > +
> > + /* Init videobuf2 queue structure */
> > + ch->vb_queue.type = V4L2_BUF_TYPE_SDR_CAPTURE;
> > + ch->vb_queue.io_modes = VB2_READ | VB2_MMAP | VB2_DMABUF;
> > + ch->vb_queue.drv_priv = ch;
> > + ch->vb_queue.buf_struct_size = sizeof(struct rcar_drif_frame_buf);
> > + ch->vb_queue.ops = &rcar_drif_vb2_ops;
> > + ch->vb_queue.mem_ops = &vb2_vmalloc_memops;
> > + ch->vb_queue.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> > +
> > + /* Init videobuf2 queue */
> > + ret = vb2_queue_init(&ch->vb_queue);
> > + if (ret) {
> > + dev_err(ch->dev, "could not initialize vb2 queue\n");
> > + return ret;
> > + }
> > +
> > + /* Init video_device structure */
> > + ch->vdev = rcar_drif_vdev;
>
> Don't embed video_device, use video_device_alloc instead. A lot of drivers
> embed this, but it turns out not to be a good idea. So new drivers should
> use video_device_alloc.
Agreed.
Thanks,
Ramesh
^ permalink raw reply
* Re: [PATCH v8 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager
From: Rob Herring @ 2016-11-14 16:11 UTC (permalink / raw)
To: Joel Holdsworth
Cc: atull, moritz.fischer, geert, devicetree, linux-kernel, linux-spi,
marex, clifford
In-Reply-To: <1478486962-26794-2-git-send-email-joel@airwebreathe.org.uk>
On Sun, Nov 06, 2016 at 07:49:21PM -0700, Joel Holdsworth wrote:
> This adds documentation of the device tree bindings of the Lattice iCE40
> FPGA driver for the FPGA manager framework.
>
> Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>
> ---
> .../bindings/fpga/lattice-ice40-fpga-mgr.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [refpolicy] su_exec
From: Fakim, Walid @ 2016-11-14 16:11 UTC (permalink / raw)
To: refpolicy
Hi Guys,
So for this process am trying to confine, the startup script is using su -c rather than runuser and even though I've got su_exec(mydomain_t) in my te file, it's prompting for a password at startup.
Any thoughts or experience of seeing this before?
Thanks.
Best Regards,
Walid Fakim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20161114/42803cab/attachment.html
^ permalink raw reply
* [U-Boot] [PATCH] dfu: dfu_sf: Fix read offset
From: Lukasz Majewski @ 2016-11-14 16:11 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1479136769-24051-1-git-send-email-phil.edworthy@renesas.com>
Hi Phil,
> The offset was applied to write, but not read, now its applied to
> both.
>
> Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
> ---
> drivers/dfu/dfu_sf.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dfu/dfu_sf.c b/drivers/dfu/dfu_sf.c
> index 9702eee..b6d5fe2 100644
> --- a/drivers/dfu/dfu_sf.c
> +++ b/drivers/dfu/dfu_sf.c
> @@ -20,7 +20,8 @@ static long dfu_get_medium_size_sf(struct
> dfu_entity *dfu) static int dfu_read_medium_sf(struct dfu_entity
> *dfu, u64 offset, void *buf, long *len)
> {
> - return spi_flash_read(dfu->data.sf.dev, offset, *len, buf);
> + return spi_flash_read(dfu->data.sf.dev, dfu->data.sf.start +
> offset,
> + *len, buf);
> }
>
> static u64 find_sector(struct dfu_entity *dfu, u64 start, u64 offset)
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply
* Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver
From: Rob Herring @ 2016-11-14 16:10 UTC (permalink / raw)
To: Andi Shyti
Cc: Jacek Anaszewski, Mauro Carvalho Chehab, Sean Young, Mark Rutland,
Richard Purdie, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, Linux LED Subsystem,
linux-kernel@vger.kernel.org
In-Reply-To: <20161110100203.2qv6j6acywpjerfi@gangnam.samsung>
On Thu, Nov 10, 2016 at 4:02 AM, Andi Shyti <andi.shyti@samsung.com> wrote:
> Hi Jacek,
>
>> > > > > Only DT bindings of LED class drivers should be placed in
>> > > > > Documentation/devicetree/bindings/leds. Please move it to the
>> > > > > media bindings.
>> > > >
>> > > > that's where I placed it first, but Rob asked me to put it in the
>> > > > LED directory and Cc the LED mailining list.
>> > > >
>> > > > That's the discussion of the version 2:
>> > > >
>> > > > https://lkml.org/lkml/2016/9/12/380
>> > > >
>> > > > Rob, Jacek, could you please agree where I can put the binding?
>> > >
>> > > I'm not sure if this is a good approach. I've noticed also that
>> > > backlight bindings have been moved to leds, whereas they don't look
>> > > similarly.
>> > >
>> > > We have common.txt LED bindings, that all LED class drivers' bindings
>> > > have to follow. Neither backlight bindings nor these ones do that,
>> > > which introduces some mess.
>> >
>> > And there are probably LED bindings that don't follow common.txt either.
>> >
>> > > Eventually adding a sub-directory, e.g. remote_control could make it
>> > > somehow logically justified, but still - shouldn't bindings be
>> > > placed in the documentation directory related to the subsystem of the
>> > > driver they are predestined to?
>> >
>> > No. While binding directories often mirror the driver directories, they
>> > are not the same. Bindings are grouped by types of h/w and IR LEDs are a
>> > type of LED.
>> >
>> > If you prefer a sub-dir, that is fine with me.
>>
>> Fine. So how about sub-dir "ir" ?
>
> would we put here all the remote control bindings that currently
> are under media?
No. Only if they are just an LED that happens to be IR.
Rob
^ permalink raw reply
* Re: [PATCH] sd_zbc: Force use of READ16/WRITE16
From: Christoph Hellwig @ 2016-11-14 16:10 UTC (permalink / raw)
To: Damien Le Moal
Cc: Jens Axboe, linux-block, linux-scsi, Christoph Hellwig,
Martin K . Petersen, Hannes Reinecke, Shaun Tancheff
In-Reply-To: <1478843606-15647-1-git-send-email-damien.lemoal@wdc.com>
Looks fine,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver
From: Rob Herring @ 2016-11-14 16:10 UTC (permalink / raw)
To: Andi Shyti
Cc: Jacek Anaszewski, Mauro Carvalho Chehab, Sean Young, Mark Rutland,
Richard Purdie,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux LED Subsystem,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161110100203.2qv6j6acywpjerfi-8vUhnHFVuGn35fTxX1Dczw@public.gmane.org>
On Thu, Nov 10, 2016 at 4:02 AM, Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> Hi Jacek,
>
>> > > > > Only DT bindings of LED class drivers should be placed in
>> > > > > Documentation/devicetree/bindings/leds. Please move it to the
>> > > > > media bindings.
>> > > >
>> > > > that's where I placed it first, but Rob asked me to put it in the
>> > > > LED directory and Cc the LED mailining list.
>> > > >
>> > > > That's the discussion of the version 2:
>> > > >
>> > > > https://lkml.org/lkml/2016/9/12/380
>> > > >
>> > > > Rob, Jacek, could you please agree where I can put the binding?
>> > >
>> > > I'm not sure if this is a good approach. I've noticed also that
>> > > backlight bindings have been moved to leds, whereas they don't look
>> > > similarly.
>> > >
>> > > We have common.txt LED bindings, that all LED class drivers' bindings
>> > > have to follow. Neither backlight bindings nor these ones do that,
>> > > which introduces some mess.
>> >
>> > And there are probably LED bindings that don't follow common.txt either.
>> >
>> > > Eventually adding a sub-directory, e.g. remote_control could make it
>> > > somehow logically justified, but still - shouldn't bindings be
>> > > placed in the documentation directory related to the subsystem of the
>> > > driver they are predestined to?
>> >
>> > No. While binding directories often mirror the driver directories, they
>> > are not the same. Bindings are grouped by types of h/w and IR LEDs are a
>> > type of LED.
>> >
>> > If you prefer a sub-dir, that is fine with me.
>>
>> Fine. So how about sub-dir "ir" ?
>
> would we put here all the remote control bindings that currently
> are under media?
No. Only if they are just an LED that happens to be IR.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: What to do about Offline_Uncorrectable and Pending_Sector in RAID1
From: Phil Turmel @ 2016-11-14 16:10 UTC (permalink / raw)
To: Bruce Merry, Wols Lists; +Cc: linux-raid
In-Reply-To: <CAHy4j_5gROfjf42VwLxDfmdc6rKYdrWoBy6u2kDefx_Yzzn9kA@mail.gmail.com>
On 11/14/2016 11:03 AM, Bruce Merry wrote:
> On 14 November 2016 at 17:58, Wols Lists <antlists@youngman.org.uk> wrote:
>> On 14/11/16 15:52, Bruce Merry wrote:
>>> On 13 November 2016 at 23:06, Wols Lists <antlists@youngman.org.uk> wrote:
>>>>> Sounds like that drive could need replacing. I'd get a new drive and do
>>>>> that as soon as possible - use the --replace option of mdadm - don't
>>>>> fail the old drive and add the new.
>>> Would you mind explaining why I should use --replace instead of taking
>>> out the suspect drive? I guess I lose redundancy for any writes that
>>> occur while the rebuild is happening, but I'd plan to do this with the
>>> filesystem unmounted so there wouldn't be any writes.
>>
>> Because a replace will copy from the old drive to the new, recovering
>> any failures from the rest of the array. A fail-and-add will have to
>> rebuild the entire new array from what's left of the old, stressing the
>> old array much more.
I entirely endorse Anthony's advice on this one. You are at great risk
of not completing a fail/add resync with the new drive.
> Okay, I can see how for RAID5 that might be a bad thing.
>
> In my case however, it sounds like --replace will copy everything from
> the failing drive, whereas I'd rather it copied everything from the
> good drive. Same stress on the array, less chance of copying dodgy
> data.
You simply don't have that choice, sorry. And drives returning dodgy
data is ungodly rare. The sector checksum algorithms are that good.
You have a URE crisis in your array that is far more significant.
Phil
^ permalink raw reply
* Re: A Transformation of our Global Context
From: Adam C. Emerson @ 2016-11-14 16:08 UTC (permalink / raw)
To: Bassam Tabbara
Cc: Yehuda Sadeh-Weinraub, Sage Weil, Gregory Farnum,
The Sacred Order of the Squid Cybernetic
In-Reply-To: <BLUPR0301MB200478F7C6DC349474A0B5F8A7BB0@BLUPR0301MB2004.namprd03.prod.outlook.com>
On 11/11/2016, Bassam Tabbara wrote:
> Yehuda, when I looked at this a few months ago, I thought there
> might be a way to make it less of an annoyance. If we can remove the
> clock_skew and figure out a way around dout/logging (i.e. make those
> process wide) then the number of classes we would need to pass the
> context to is greatly reduced. This is roughly the path we take for
> the clients (librados for example). I’ll try to prototype this over
> the next few weeks as we would love to be able to run multiple OSDs
> and MONs in the same process.
That was something like my original idea, that we coudl factor the
dout support out of CephContext and have it be a per-thread variable,
ideally set up as a fluid so we could annotate the call path. (So that
some function way down at the bottom of the call stack would log
things and still know that it was called by osd.3 or mds.5 or what
have you.)
--
Senior Software Engineer Red Hat Storage, Ann Arbor, MI, US
IRC: Aemerson@{RedHat, OFTC, Freenode}
0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C 7C12 80F7 544B 90ED BFB9
^ permalink raw reply
* Re: What to do about Offline_Uncorrectable and Pending_Sector in RAID1
From: Bruce Merry @ 2016-11-14 16:09 UTC (permalink / raw)
To: Phil Turmel; +Cc: Wols Lists, linux-raid
In-Reply-To: <1c3c5ce1-a26e-878d-9863-399efe6825e1@turmel.org>
On 14 November 2016 at 18:01, Phil Turmel <philip@turmel.org> wrote:
> In the meantime, run a "repair" scrub instead of a "check" scrub to
> affirmatively force no mismatches. (Writes first member of mirrors to
> the others.)
I think that's good news. I wasn't sure which direction "repair" would
copy, but the good drive is the first member ("Device Role : Active
device 0"). I'll give that a go once the current scrub is done.
Thanks
Bruce
--
Dr Bruce Merry
bmerry <@> gmail <.> com
http://www.brucemerry.org.za/
http://blog.brucemerry.org.za/
^ permalink raw reply
* Re: What to do about Offline_Uncorrectable and Pending_Sector in RAID1
From: Wols Lists @ 2016-11-14 16:09 UTC (permalink / raw)
To: Bruce Merry; +Cc: linux-raid
In-Reply-To: <CAHy4j_5gROfjf42VwLxDfmdc6rKYdrWoBy6u2kDefx_Yzzn9kA@mail.gmail.com>
On 14/11/16 16:03, Bruce Merry wrote:
> On 14 November 2016 at 17:58, Wols Lists <antlists@youngman.org.uk> wrote:
>> On 14/11/16 15:52, Bruce Merry wrote:
>>> On 13 November 2016 at 23:06, Wols Lists <antlists@youngman.org.uk> wrote:
>>>>> Sounds like that drive could need replacing. I'd get a new drive and do
>>>>> that as soon as possible - use the --replace option of mdadm - don't
>>>>> fail the old drive and add the new.
>>> Would you mind explaining why I should use --replace instead of taking
>>> out the suspect drive? I guess I lose redundancy for any writes that
>>> occur while the rebuild is happening, but I'd plan to do this with the
>>> filesystem unmounted so there wouldn't be any writes.
>>
>> Because a replace will copy from the old drive to the new, recovering
>> any failures from the rest of the array. A fail-and-add will have to
>> rebuild the entire new array from what's left of the old, stressing the
>> old array much more.
>
> Okay, I can see how for RAID5 that might be a bad thing.
>
> In my case however, it sounds like --replace will copy everything from
> the failing drive, whereas I'd rather it copied everything from the
> good drive. Same stress on the array, less chance of copying dodgy
> data.
>
So long as the data on the drive is correct (it should be) and the drive
reports a fault where it can't read it, it'll only copy good data off
the bad drive. It'll copy it from the other drive if it's dud.
Cheers,
Wol
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Batch tlb flush when invalidating pte entries
From: Aneesh Kumar K.V @ 2016-11-14 16:08 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev
In-Reply-To: <20161114155857.25046-1-aneesh.kumar@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> This will improve the task exit case, by batching tlb invalidates.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/radix.h | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/radix.h b/arch/powerpc/include/asm/book3s/64/radix.h
> index aec6e8ee6e27..e8b4f39e9fab 100644
> --- a/arch/powerpc/include/asm/book3s/64/radix.h
> +++ b/arch/powerpc/include/asm/book3s/64/radix.h
> @@ -147,10 +147,16 @@ static inline unsigned long radix__pte_update(struct mm_struct *mm,
> * new value of pte
> */
> new_pte = (old_pte | set) & ~clr;
> - psize = radix_get_mmu_psize(pg_sz);
> - radix__flush_tlb_page_psize(mm, addr, psize);
> -
> - __radix_pte_update(ptep, 0, new_pte);
> + /*
> + * If we are trying to clear the pte, we can skip
> + * the below sequence and batch the tlb flush. The
> + * tlb flush batching is done by mmu gather code
> + */
> + if (new_pte) {
> + psize = radix_get_mmu_psize(pg_sz);
> + radix__flush_tlb_page_psize(mm, addr, psize);
> + __radix_pte_update(ptep, 0, new_pte);
> + }
> } else
> old_pte = __radix_pte_update(ptep, clr, set);
> asm volatile("ptesync" : : : "memory");
We can also avoid the ptesync I guess. BTW for transition from V=0 to
a valid pte, we are good without this patch because that is done via set_pte_at()
diff --git a/arch/powerpc/include/asm/book3s/64/radix.h b/arch/powerpc/include/asm/book3s/64/radix.h
index e8b4f39e9fab..83c77323a769 100644
--- a/arch/powerpc/include/asm/book3s/64/radix.h
+++ b/arch/powerpc/include/asm/book3s/64/radix.h
@@ -142,7 +142,6 @@ static inline unsigned long radix__pte_update(struct mm_struct *mm,
unsigned long new_pte;
old_pte = __radix_pte_update(ptep, ~0, 0);
- asm volatile("ptesync" : : : "memory");
/*
* new value of pte
*/
@@ -153,6 +152,7 @@ static inline unsigned long radix__pte_update(struct mm_struct *mm,
* tlb flush batching is done by mmu gather code
*/
if (new_pte) {
+ asm volatile("ptesync" : : : "memory");
psize = radix_get_mmu_psize(pg_sz);
radix__flush_tlb_page_psize(mm, addr, psize);
__radix_pte_update(ptep, 0, new_pte);
^ permalink raw reply related
* Re: [PATCH 4/4] sanity.bbclass: fix check_connectivity() for BB_NO_NETWORK = "0"
From: Christopher Larson @ 2016-11-14 16:08 UTC (permalink / raw)
To: Robert Yang; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4e2659f6-3cbf-5d91-7a08-9675657d4495@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 3686 bytes --]
On Mon, Nov 14, 2016 at 9:05 AM, Robert Yang <liezhi.yang@windriver.com>
wrote:
> On 11/14/2016 11:38 PM, Christopher Larson wrote:
>
>>
>> On Mon, Nov 14, 2016 at 8:37 AM, Robert Yang <liezhi.yang@windriver.com
>> <mailto:liezhi.yang@windriver.com>> wrote:
>>
>> On 11/14/2016 11:03 PM, Christopher Larson wrote:
>>
>>
>> On Mon, Nov 14, 2016 at 7:34 AM, Robert Yang <
>> liezhi.yang@windriver.com
>> <mailto:liezhi.yang@windriver.com>
>> <mailto:liezhi.yang@windriver.com <mailto:liezhi.yang@windriver.
>> com>>>
>> wrote:
>>
>> The old code:
>> network_enabled = not d.getVar('BB_NO_NETWORK', True)
>>
>> It is True only when BB_NO_NETWORK is not set (None),
>> but BB_NO_NETWORK = "0" should also be True while "1" means
>> no network,
>> "0" means need network in a normal case.
>>
>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com
>> <mailto:liezhi.yang@windriver.com>
>> <mailto:liezhi.yang@windriver.com <mailto:
>> liezhi.yang@windriver.com>>>
>>
>> ---
>> meta/classes/sanity.bbclass | 14 +++++++++-----
>> 1 file changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/meta/classes/sanity.bbclass
>> b/meta/classes/sanity.bbclass
>> index 7e383f9..c5e3809 100644
>> --- a/meta/classes/sanity.bbclass
>> +++ b/meta/classes/sanity.bbclass
>> @@ -363,15 +363,19 @@ def check_connectivity(d):
>> test_uris = (d.getVar('CONNECTIVITY_CHECK_URIS', True)
>> or
>> "").split()
>> retval = ""
>>
>> + bbn = d.getVar('BB_NO_NETWORK', True)
>> + if bbn not in (None, '0', '1'):
>> + return 'BB_NO_NETWORK should be "0" or "1", but it
>> is "%s"'
>> % bbn
>>
>>
>> Does this mirror the same logic used in bitbake? What’s the
>> behavior if it’s
>> set, but to the empty string?
>>
>>
>> bitbake only checks whether it equals "1" or not. Without this patch,
>> an empty
>> string is the same as not set since it doesn't equal to "1". But if
>> it is
>> set to "0", bitbake uses it as enable network, sanity.bbclass uses it
>> as disable netowrk, which are conflicted. We can add checking for
>> empty string,
>> but do we have to ? Limit it to "0" or "1" makes things clear.
>>
>>
>> IMO if we’re going to change the semantics, we should do it in bitbake
>> and then
>> mirror that in the metadata. Sanity checking should mirror the actual
>> variable
>> behavior where it’s used.
>>
>
> Sounds reasonable, but I'm not sure how to do it, ways I can think out:
> 1) Handle "0" as enable network as bitbake does in sanity.bbclass
> 2) If we want to limit its values, maybe we need check it in bitbake rather
> than in sanity.bbclass, there are also other values have the similar
> problems, I did a rough grep, such as BB_FETCH_PREMIRRORONLY:
>
> fetch2/__init__.py: premirroronly = (self.d.getVar("BB_FETCH_PREMIRRORONLY",
> True) == "1")
> fetch2/git.py: if d.getVar("BB_FETCH_PREMIRRORONLY", True) is not
> None:
>
> The __init__.py only checks whether it is "1" or not, but git.py checks if
> it
> is None, there would be confusions when it is "" or "0".
Sounds like bb.utils.to_boolean() may be our friend for a number of these.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 5511 bytes --]
^ permalink raw reply
* Re: [RFC 09/14] SoundWire: Add support to handle Slave status change
From: Charles Keepax @ 2016-11-14 16:08 UTC (permalink / raw)
To: Hardik Shah
Cc: alsa-devel, linux-kernel, tiwai, pierre-louis.bossart, broonie,
lgirdwood, plai, patches.audio, Sanyog Kale
In-Reply-To: <1477053673-16021-10-git-send-email-hardik.t.shah@intel.com>
On Fri, Oct 21, 2016 at 06:11:07PM +0530, Hardik Shah wrote:
> This patch adds the support for updating the Slave status to bus driver.
> Master driver updates Slave status change to the bus driver. Bus driver
> takes appropriate action on Slave status change like.
>
> 1. Registering new device if new Slave got enumerated on bus.
> 2. Assigning the device number to the Slave device
> 3. Marking Slave as un-attached if Slave got detached from bus.
> 4. Handling Slave alerts.
>
> Signed-off-by: Hardik Shah <hardik.t.shah@intel.com>
> Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> ---
> sound/sdw/sdw.c | 1074 ++++++++++++++++++++++++++++++++++++++++++++++++++
> sound/sdw/sdw_priv.h | 66 ++++
> 2 files changed, 1140 insertions(+)
>
<snip>
> +static int sdw_slv_register(struct sdw_master *mstr)
> +{
> + int ret, i;
> + struct sdw_msg msg;
> + u8 buf[SDW_NUM_DEV_ID_REGISTERS];
> + struct sdw_slave *sdw_slave;
> + int dev_num = -1;
> + bool found = false;
> +
> + /* Create message to read the 6 dev_id registers */
> + sdw_create_rd_msg(&msg, 0, SDW_SCP_DEVID_0, SDW_NUM_DEV_ID_REGISTERS,
> + buf, 0x0);
> +
> + /*
> + * Multiple Slaves may report an Attached_OK status as Device0.
> + * Since the enumeration relies on a hardware arbitration and is
> + * done one Slave at a time, a loop needs to run until all Slaves
> + * have been assigned a non-zero DeviceNumber. The loop exits when
> + * the reads from Device0 devID registers are no longer successful,
> + * i.e. there is no Slave left to enumerate
> + */
> + while ((ret = (snd_sdw_slave_transfer(mstr, &msg, SDW_NUM_OF_MSG1_XFRD))
> + == SDW_NUM_OF_MSG1_XFRD)) {
> +
> + /*
> + * Find is Slave is re-enumerating, and was already
> + * registered earlier.
> + */
> + found = sdw_find_slv(mstr, &msg, &dev_num);
> +
> + /*
> + * Reprogram the Slave device number if its getting
> + * re-enumerated. If that fails we continue finding new
> + * slaves, we flag error but don't stop since there may be
> + * new Slaves trying to get enumerated.
> + */
> + if (found) {
> + ret = sdw_program_dev_num(mstr, dev_num);
> + if (ret < 0)
> + dev_err(&mstr->dev, "Re-registering slave failed ret = %d", ret);
> +
> + continue;
> +
> + }
> +
> + /*
> + * Find the free device_number for the new Slave getting
> + * enumerated 1st time.
> + */
> + dev_num = sdw_find_free_dev_num(mstr, &msg);
> + if (dev_num < 0) {
> + dev_err(&mstr->dev, "Failed to find free dev_num ret = %d\n", ret);
> + goto dev_num_assign_fail;
> + }
> +
> + /*
> + * Allocate and initialize the Slave device on first
> + * enumeration
> + */
> + sdw_slave = kzalloc(sizeof(*sdw_slave), GFP_KERNEL);
> + if (!sdw_slave) {
> + ret = -ENOMEM;
> + goto mem_alloc_failed;
> + }
> +
> + /*
> + * Initialize the allocated Slave device, set bus type and
> + * device type to SoundWire.
> + */
> + sdw_slave->mstr = mstr;
> + sdw_slave->dev.parent = &sdw_slave->mstr->dev;
> + sdw_slave->dev.bus = &sdw_bus_type;
> + sdw_slave->dev.type = &sdw_slv_type;
> + sdw_slave->priv.addr = &mstr->sdw_addr[dev_num];
> + sdw_slave->priv.addr->slave = sdw_slave;
> +
> + for (i = 0; i < SDW_NUM_DEV_ID_REGISTERS; i++)
> + sdw_slave->priv.dev_id[i] = msg.buf[i];
> +
> + dev_dbg(&mstr->dev, "SDW slave slave id found with values\n");
> + dev_dbg(&mstr->dev, "dev_id0 to dev_id5: %x:%x:%x:%x:%x:%x\n",
> + msg.buf[0], msg.buf[1], msg.buf[2],
> + msg.buf[3], msg.buf[4], msg.buf[5]);
> + dev_dbg(&mstr->dev, "Dev number assigned is %x\n", dev_num);
> +
> + /*
> + * Set the Slave device name, its based on the dev_id and
> + * to bus which it is attached.
> + */
> + dev_set_name(&sdw_slave->dev, "sdw-slave%d-%02x:%02x:%02x:%02x:%02x:%02x",
> + sdw_master_get_id(mstr),
> + sdw_slave->priv.dev_id[0],
> + sdw_slave->priv.dev_id[1],
> + sdw_slave->priv.dev_id[2],
> + sdw_slave->priv.dev_id[3],
> + sdw_slave->priv.dev_id[4],
> + sdw_slave->priv.dev_id[5]);
> +
> + /*
> + * Set name based on dev_id. This will be used in match
> + * function to bind the device and driver.
> + */
> + sprintf(sdw_slave->priv.name, "%02x:%02x:%02x:%02x:%02x:%02x",
> + sdw_slave->priv.dev_id[0],
> + sdw_slave->priv.dev_id[1],
> + sdw_slave->priv.dev_id[2],
> + sdw_slave->priv.dev_id[3],
> + sdw_slave->priv.dev_id[4],
> + sdw_slave->priv.dev_id[5]);
> + ret = device_register(&sdw_slave->dev);
> + if (ret) {
> + dev_err(&mstr->dev, "Register slave failed ret = %d\n", ret);
> + goto reg_slv_failed;
> + }
There are some issues with this, as the slave driver only probes
when the device actually shows up on the bus. However often
(especially in embedded contexts) some things may need to be
done to enable the slave. For example it may be held in reset or
its power supplies switched off until they are need. As such it
generally helps if the device probe can be called before it shows
up on the bus, the device probe can then do the necessary actions
to enable the device at which point it will show up on the bus.
Thanks,
Charles
^ permalink raw reply
* ceph branch status
From: ceph branch robot @ 2016-11-14 16:00 UTC (permalink / raw)
To: ceph-devel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 30139 bytes --]
-- All Branches --
Adam Crume <adamcrume@gmail.com>
2014-12-01 20:45:58 -0800 wip-doc-rbd-replay
Adam Kupczyk <akupczyk@mirantis.com>
2016-10-06 11:04:05 +0200 wip-pr-10504
Alfredo Deza <adeza@redhat.com>
2016-10-07 09:01:04 -0400 wip-16125
Ali Maredia <amaredia@redhat.com>
2016-05-17 18:41:19 -0400 wip-cmake-librados
2016-06-30 14:57:17 -0400 wip-blkin-osdc
Anirudha Bose <ani07nov@gmail.com>
2016-08-20 03:43:05 +0530 wip-volume-client-py3
Bassam Tabbara <bassam.tabbara@quantum.com>
2016-09-23 07:56:05 -0700 wip-pr-11086
Boris Ranto <branto@redhat.com>
2015-09-04 15:19:11 +0200 wip-bash-completion
Brad Hubbard <bhubbard@redhat.com>
2016-10-18 11:28:44 +1000 wip-badone-testing
Casey Bodley <cbodley@redhat.com>
2016-10-05 12:05:36 -0400 wip-cbodley-testing
2016-10-07 11:19:53 -0400 wip-config-leak-bisect
2016-11-10 08:56:09 -0500 wip-17792
2016-11-11 14:06:48 -0500 wip-rgw-compression-type-random
Daniel Gryniewicz <dang@redhat.com>
2015-11-11 09:06:00 -0500 wip-rgw-storage-class
2016-08-31 12:00:42 -0400 dang-build
2016-10-12 12:01:28 -0400 jewel-default-quota
Danny Al-Gaaf <danny.al-gaaf@bisect.de>
2015-04-23 16:32:00 +0200 wip-da-SCA-20150421
2015-04-23 17:18:57 +0200 wip-nosetests
2015-04-23 18:20:16 +0200 wip-unify-num_objects_degraded
2016-04-27 00:22:25 +0200 wip-da-SCA-20160426
David Zafman <dzafman@redhat.com>
2016-10-13 09:30:59 -0700 wip-zafman-hf
2016-10-20 23:22:23 -0700 wip-zafman-testing-new
2016-11-07 15:22:45 -0800 wip-zafman-testing
Dongmao Zhang <deanraccoon@gmail.com>
2014-11-14 19:14:34 +0800 thesues-master
Douglas Fuller <dfuller@redhat.com>
2016-05-17 07:16:09 -0700 wip-djf-15028
2016-05-19 06:09:37 -0700 wip-djf-object-map-check
2016-09-06 11:14:41 -0700 wip-djf-15069
GitHub <noreply@github.com>
2016-06-17 14:46:11 -0700 wip-sam-master-16-06-17
2016-06-27 17:51:19 +0200 wip-optracker-4354
2016-08-26 16:57:10 +0800 0.94.2
2016-09-29 21:34:26 -0700 wip-hammer-bucket-reshard
2016-09-30 15:40:35 -0700 master_2016_10_05-alfredo
2016-10-10 21:07:44 +0300 wip-rbd-mirror-ha
2016-10-18 12:20:16 +0200 wip-master-loic
2016-10-26 11:35:59 -0400 kraken
2016-10-29 10:24:18 +0200 hammer
2016-11-02 08:42:35 +0200 infernalis
2016-11-09 20:53:18 +0100 jewel
2016-11-14 16:42:36 +0100 jewel-next
Greg Farnum <gfarnum@redhat.com>
2016-10-25 16:14:00 -0700 wip-no-pastparents
Guang G Yang <yguang@renownedground.corp.gq1.yahoo.com>
2015-06-26 20:31:44 +0000 wip-ec-readall
2015-07-23 16:13:19 +0000 wip-12316
Guang Yang <yguang@yahoo-inc.com>
2014-09-25 00:47:46 +0000 wip-9008
2015-10-20 15:30:41 +0000 wip-13441
Haomai Wang <haomai@xsky.com>
2015-10-26 00:02:04 +0800 wip-13521
2016-05-25 09:02:18 +0800 wip-15758
2016-07-15 01:00:20 +0800 wip-16685
2016-08-03 13:25:00 +0800 wip-haomai-testing
Haomai Wang <haomaiwang@gmail.com>
2015-07-21 19:33:56 +0800 fio-objectstore
Hector Martin <marcan@marcan.st>
2015-12-03 03:07:02 +0900 wip-cython-rbd
Ilya Dryomov <idryomov@gmail.com>
2016-09-07 15:10:12 +0200 wip-17223-jewel
2016-09-21 16:17:28 +0200 wip-rasize-doc-jewel
Ivo Jimenez <ivo.jimenez@gmail.com>
2015-08-24 23:12:45 -0700 hammer-with-new-workunit-for-wip-12551
J. Eric Ivancich <ivancich@redhat.com>
2016-09-07 13:33:19 -0400 wip_dmc2_mod_weights
2016-09-08 12:12:17 -0400 wip_dmc2_limits
2016-09-27 00:24:42 -0400 wip_dmc2_ooo_instrum
2016-09-30 15:41:40 -0400 wip_dmclock2_rebase
2016-09-30 18:18:26 -0400 wip_dmclock2
2016-11-10 14:30:47 -0500 wip_dmc2_mod_weights_tracing
James Page <james.page@ubuntu.com>
2015-11-04 11:08:42 +0000 javacruft-wip-ec-modules
Jason Dillaman <dillaman@redhat.com>
2016-11-11 08:55:59 -0500 wip-jd-testing
Jenkins <jenkins@inktank.com>
2014-07-29 05:24:39 -0700 wip-nhm-hang
2014-10-14 12:10:38 -0700 wip-2
2015-02-02 10:35:28 -0800 wip-sam-v0.92
2015-08-21 12:46:32 -0700 last
2015-08-21 12:46:32 -0700 loic-v9.0.3
2015-09-15 10:23:18 -0700 rhcs-v0.80.8
2015-09-21 16:48:32 -0700 rhcs-v0.94.1-ubuntu
Jenkins Build Slave User <ceph-release-team@redhat.com>
2016-09-20 22:04:23 +0000 wip-zg-default
Joao Eduardo Luis <jeclui@gmail.com>
2014-09-10 09:39:23 +0100 wip-leveldb-get.dumpling
Joao Eduardo Luis <joao.luis@gmail.com>
2014-07-22 15:41:42 +0100 wip-leveldb-misc
Joao Eduardo Luis <joao.luis@inktank.com>
2014-09-02 17:19:52 +0100 wip-leveldb-get
2014-10-17 16:20:11 +0100 wip-paxos-fix
2014-10-21 21:32:46 +0100 wip-9675.dumpling
2015-07-27 21:56:42 +0100 wip-11470.hammer
2015-09-09 15:45:45 +0100 wip-11786.hammer
Joao Eduardo Luis <joao@redhat.com>
2014-11-17 16:43:53 +0000 wip-mon-osdmap-cleanup
2014-12-15 16:18:56 +0000 wip-giant-mon-backports
2014-12-17 17:13:57 +0000 wip-mon-backports.firefly
2014-12-17 23:15:10 +0000 wip-mon-sync-fix.dumpling
2015-01-07 23:01:00 +0000 wip-mon-blackhole-mlog-0.87.7
2015-01-10 02:40:42 +0000 wip-dho-joao
2015-01-10 02:46:31 +0000 wip-mon-paxos-fix
2015-01-26 13:00:09 +0000 wip-mon-datahealth-fix
2015-02-04 22:36:14 +0000 wip-10643
2015-09-09 15:43:51 +0100 wip-11786.firefly
Joao Eduardo Luis <joao@suse.de>
2015-05-27 23:48:45 +0100 wip-mon-scrub
2015-05-29 12:21:43 +0100 wip-11545
2015-06-05 16:12:57 +0100 wip-10507
2015-06-16 14:34:11 +0100 wip-11470
2015-06-25 00:16:41 +0100 wip-10507-2
2015-09-08 09:48:41 +0100 wip-leveldb-hang
2016-10-29 04:10:23 +0100 wip-joao-testing
2016-11-04 00:57:16 +0000 wip-monstore-tool-sanitize-paxos.hammer
John Spray <john.spray@redhat.com>
2016-07-13 13:16:59 +0100 wip-jcsp-testing-20160713
2016-07-14 14:46:03 +0100 wip-jcsp-testing-20160714
2016-07-19 11:03:21 +0100 wip-jcsp-testing-20160719
2016-07-26 15:19:18 +0100 ceph-tests-py3
2016-07-27 12:48:15 +0100 wip-jcsp-testing-20160727
2016-07-28 12:13:32 +0100 wip-setlk
2016-08-02 00:16:42 +0100 wip-manila-backports-jewel
2016-08-02 18:06:35 +0100 wip-jcsp-testing-20160802
2016-08-05 17:14:42 +0100 wip-jcsp-testing-20160805
2016-08-07 20:27:34 +0100 wip-prompt-frag
2016-09-02 12:51:16 +0100 wip-jcsp-testing-20160902
2016-09-07 21:51:19 +0100 wip-jcsp-testing-20160907
2016-09-12 14:55:37 +0530 wip-jcsp-testing-20160912
2016-09-13 18:43:43 +0530 wip-ceph-mgr-pkg
2016-09-14 00:24:08 +0530 wip-17270
2016-09-21 19:40:47 +0100 wip-jcsp-testing-20160921
2016-09-22 12:50:31 +0100 wip-jcsp-greenish
2016-09-23 16:14:47 +0100 wip-jcsp-testing-20160923-b
2016-09-23 16:15:17 +0100 wip-jcsp-testing-20160923
2016-09-26 22:51:12 +0100 wip-jcsp-testing-20160926
2016-09-28 20:18:41 +0100 wip-ceph-mgr
2016-10-02 21:37:59 +0100 wip-jcsp-testing-20161002
2016-10-03 07:35:52 +0100 wip-17466-jewel
2016-10-03 07:42:19 +0100 wip-17466
2016-10-10 12:28:21 +0100 wip-jcsp-backports-20161010
2016-10-10 14:24:57 +0100 wip-jcsp-testing-20161010
2016-10-12 00:28:45 +0100 wip-jcsp-testing-20161012
2016-10-17 13:24:38 +0100 wip-jcsp-testing-20161017
2016-10-18 11:19:21 +0100 wip-cephfs-cleanups
2016-10-19 20:18:20 +0100 wip-jcsp-testing-20161019
2016-10-20 11:58:18 +0100 wip-jcsp-testing-20161020
2016-10-21 11:33:24 +0100 wip-jcsp-testing-20161020b
2016-10-24 13:42:37 +0100 wip-jcsp-testing-20161024
2016-10-24 18:16:52 +0100 wip-mantle-test
2016-10-27 16:50:03 +0100 wip-jcsp-testing-20161026
2016-10-28 11:44:42 +0100 wip-jcsp-trim-debug
2016-11-10 15:39:26 +0000 wip-jcsp-testing-20161108
John Wilkins <john.wilkins@inktank.com>
2013-07-31 18:00:50 -0700 wip-doc-rados-python-api
2014-07-03 07:31:14 -0700 wip-doc-rgw-federated
2014-11-03 14:04:33 -0800 wip-doc-openstack-juno
John Wilkins <jowilki@redhat.com>
2014-09-15 11:10:35 -0700 wip-doc-preflight
Josh Durgin <jdurgin@redhat.com>
2015-01-26 17:37:33 -0800 wip-10644
2015-02-26 15:00:26 -0800 wip-librbd-resize
2015-03-16 16:19:31 -0700 wip-lttng-daemon
2015-04-07 23:40:58 -0700 wip-2862
2015-08-09 22:08:23 -0700 wip-12383-next-librados
2015-08-31 12:26:30 -0700 wip-12752
2015-09-14 14:27:39 -0700 wip-rbd-write-full
2015-09-18 03:41:19 -0400 wip-blkin
2015-10-06 18:38:04 -0700 wip-infernalis-rbd
2015-12-08 15:09:54 -0800 wip-buffer-header
2016-01-08 13:42:25 -0800 wip-auth-hammer
2016-02-17 10:05:20 -0800 wip-10587
2016-04-01 18:27:48 -0700 wip-mirror-test
2016-04-07 17:11:42 -0700 wip-mirror-test2
2016-04-08 17:09:00 -0700 wip-ccache-build
2016-04-14 10:59:02 -0700 wip-rados-writesame
2016-06-03 18:46:15 -0700 wip-filestore-split-threshold
2016-06-16 08:12:54 -0700 wip-ceph-argparse-py3
2016-07-13 15:58:08 -0700 wip-googletest-centos
2016-07-22 15:22:02 -0700 wip-tests-py3
2016-07-22 15:27:35 -0700 wip-striper-async
2016-08-02 08:08:33 -0700 wip-libradosstriper-tests
2016-08-05 17:23:39 -0700 wip-offline-split-hammer
2016-08-19 12:44:26 -0700 wip-josh-testing
2016-09-19 16:43:32 -0700 wip-rocksdb-librados-orig
Josh Durgin <josh.durgin@inktank.com>
2013-03-01 14:45:23 -0800 wip-rbd-workunit-debug
2013-08-27 12:03:08 -0700 wip-krbd-workunits
2013-11-22 15:17:08 -0800 wip-zero-copy-bufferlist
2014-03-03 14:27:39 -0800 wip-object-cacher-memory
2014-04-27 14:13:07 -0700 wip-rbd-header-dump
João Eduardo Luís <joao.luis@inktank.com>
2014-10-26 18:58:50 +0000 wip-giant-old-sam
Kefu Chai <kchai@redhat.com>
2016-09-13 01:43:39 +0800 wip-17179-hammer
2016-11-02 19:23:24 +0800 wip-17728-jewel
2016-11-13 15:42:52 +0800 wip-monc-in-p
2016-11-13 16:59:56 +0800 wip-kefu-testing
2016-11-14 16:40:26 +0800 wip-17809
Ken Dreyer <kdreyer@redhat.com>
2015-02-27 12:10:43 -0700 wip-rpm-license-files
2015-07-13 15:24:25 -0600 wip-spec-tidying
2016-09-12 09:09:15 -0600 wip-14439-crush-location-manpage
2016-10-11 10:27:37 -0600 wip-jewel-tarball
Krzysztof Kosiński <krzysztof.kosinski@intel.com>
2015-07-15 14:44:42 +0200 wip-5238
Li Wang <liwang@ubuntukylin.com>
2014-12-01 09:01:55 +0800 wip-quota
Loic Dachary <ldachary@redhat.com>
2015-02-04 08:40:57 +0100 wip-sam-hammer
2015-03-23 17:44:12 +0100 dumpling
2015-10-03 23:31:47 +0200 wip-core-analysis
2015-12-04 01:00:07 +0100 wip-sage-testing-rebased
2016-03-27 22:28:50 +0200 wip-virtualenv-jewel
2016-10-21 14:31:48 +0200 wip-17262-jewel
2016-10-24 15:58:31 +0200 wip-17662-ceph-disk
2016-10-26 09:35:34 +0200 wip-17707-jewel
2016-11-04 15:35:45 +0100 wip-17734-jewel
Loic Dachary <loic@dachary.org>
2015-10-17 00:38:34 +0200 giant
2016-01-29 23:31:47 +0700 wip-test-14716-4
2016-02-10 13:11:59 +0700 infernalis-backports
2016-08-15 13:16:38 +0200 wip-16778-jewel
2016-10-19 09:35:01 +0200 jewel-backports-loic
2016-11-09 23:13:19 +0100 jewel-backports
Marcel Lauhoff <lauhoff@uni-mainz.de>
2016-01-11 13:21:02 +0100 wip-7190
Marcus Watts <mdw@cohortfs.com>
2015-08-14 12:05:21 -0400 wip-addr
Marcus Watts <mwatts@redhat.com>
2015-09-02 23:24:33 -0400 wip-rgw-sts
2016-02-23 19:11:33 -0500 wip-openssl
2016-03-28 17:27:23 -0400 wip-rgw-openssl-2
2016-06-16 02:48:14 -0400 rhcs-v0.94.3-ubuntu
2016-08-02 03:49:54 -0400 wip-rgw-asio-frontend
2016-08-09 17:59:05 -0400 wip-buildfix-system-rocksdb
2016-10-13 13:40:40 -0400 wip-hammer-rgw-0lenfix
2016-10-19 05:05:50 -0400 wip-master-rgw-0lenfix1
2016-10-19 05:11:47 -0400 wip-jewel-rgw-0lenfix1
2016-11-09 01:59:36 -0500 wip-rgw-openssl-7
2016-11-11 01:22:10 -0500 wip-xml-string-wrap
2016-11-11 01:24:44 -0500 wip-rgw-http-getcmd
2016-11-11 01:25:55 -0500 wip-json-smarter-escapes
2016-11-11 01:29:56 -0500 wip-buildfix-python-out-of-tree
2016-11-14 00:40:06 -0500 wip-rgw-polymorphic-errors
Mark Nelson <mnelson@redhat.com>
2016-08-09 10:29:31 -0500 wip-mark-testing
Matt Benjamin <mbenjamin@redhat.com>
2015-08-24 17:44:26 -0400 wip-xio
2016-09-13 00:29:10 -0400 wip-matt-testing-normalize
2016-09-13 06:08:52 -0400 wip-matt-testing-notempty
2016-10-07 09:48:54 -0400 jewel-s3-versioning-backports
Mehdi Abaakouk <sileht@redhat.com>
2016-02-29 11:36:57 +0100 wip-test-cython
Michel Normand <normand@linux.vnet.ibm.com>
2016-08-11 10:38:06 +0200 wip-16937
Mykola Golub <mgolub@mirantis.com>
2016-11-04 08:05:39 +0200 wip-mgolub-testing
2016-11-14 09:24:34 +0200 wip-mgolub-testing-jewel
Nathan Cutler <ncutler@suse.com>
2016-06-17 17:13:32 +0200 wip-nathan-testing
2016-07-01 15:44:24 +0200 hammer-backports-20160708
2016-07-24 21:26:22 +0200 hammer-backports
2016-08-03 12:30:49 +0200 wip-16345
2016-08-07 23:10:38 +0200 wip-16949
2016-08-08 23:26:26 +0200 wip-16960
2016-08-22 20:56:38 +0200 wip-17092-jewel
2016-08-23 08:44:40 +0200 wip-16353
2016-09-05 15:44:56 +0200 wip-fix-install-deps
Noah Watkins <noah.watkins@inktank.com>
2016-01-23 22:08:58 +0000 cls-lua-loadfile
Orit Wasserman <owasserm@redhat.com>
2016-09-19 18:00:54 +0200 wip-17167
2016-10-19 23:25:47 +0200 wip-jewel-acl-underscore
2016-10-24 19:32:39 +0200 wip-jewel-11567
2016-10-27 20:27:54 +0200 wip-jewel-11566
2016-10-31 12:43:20 +0100 wip-orit-17440
2016-11-09 11:29:04 +0100 wip-orit-testing
2016-11-10 16:17:05 +0100 wip-rgw-fix-period-commit
2016-11-12 14:29:55 +0100 wip-hammer-11567
Owen Synge <osynge@googlemail.com>
2015-05-27 08:28:53 +0000 wip-git_ignore_systemd_autotools_template_systemd_ceph_osd
2015-06-15 15:23:51 +0000 wip-4898
Patrick Donnelly <pdonnell@redhat.com>
2016-10-25 14:07:22 -0400 wip-multimds-tests
Pritha Srivastava <prsrivas@redhat.com>
2016-08-09 20:17:15 +0530 wip_s3_v2_local_auth_rework
2016-08-22 12:43:44 +0530 wip_s3_keystone_rework
2016-09-08 14:55:59 +0530 wip-rgw-seven-for-sts
Radoslaw Zarzynski <rzarzynski@mirantis.com>
2016-08-22 15:55:28 +0200 wip-radek-testing
2016-10-25 18:28:26 +0200 wip-rgw-frontend-rework
Ramana Raja <rraja@redhat.com>
2016-10-26 12:24:20 +0530 wip-17705-jewel
Ricardo Dias <rdias@suse.com>
2016-08-30 08:29:00 +0100 wip-16776
2016-09-21 23:10:37 +0100 wip-rdias-testing
Roald van Loon <roald@roaldvanloon.nl>
2012-12-24 22:26:56 +0000 wip-dout
Rémi BUISSON <remi.buisson@cdiscount.com>
2016-08-26 11:55:41 +0200 wip-Cdiscount
Sage Weil <sage@inktank.com>
2012-11-30 13:47:27 -0800 wip-osd-readhole
2013-01-29 13:46:02 -0800 wip-readdir
2013-04-18 13:51:36 -0700 argonaut
2013-09-19 12:08:45 -0700 wip-neon-crc32c
2013-12-07 16:04:15 -0800 wip-journaler-kludge
2014-01-06 22:13:09 -0800 wip-librados
2014-03-05 15:14:26 -0800 wip-6101
2014-03-16 09:50:31 -0700 wip-dumpling-sloppy-log
2014-03-24 17:22:52 -0700 wip-7779
2014-04-01 13:07:57 -0700 wip-rest-api-init
2014-04-02 08:49:33 -0700 wip-ms-dump
2014-04-08 12:48:49 -0700 wip-debug-pgrefs
2014-04-10 07:04:17 -0700 wip-fuse-reconnect
2014-04-19 21:13:23 -0700 wip-f2fs
2014-07-01 17:15:03 -0700 wip-7995
2014-07-03 15:06:53 -0700 wip-poll-timeout
Sage Weil <sage@redhat.com>
2014-06-18 21:34:57 -0700 wip-disk-ioprio-dumpling
2014-06-18 21:34:57 -0700 wip-scrub-sleep-dumpling
2014-06-30 17:54:58 -0700 wip-osd-map-cache-size
2014-07-15 09:36:32 -0700 wip-journal-sync
2014-07-16 18:04:07 -0700 wip-8632-dumpling
2014-07-19 15:20:05 -0700 wip-transaction
2014-08-05 11:03:08 -0700 wip-firefly-isa
2014-08-06 10:55:24 -0700 wip-libcommon
2014-08-06 17:04:02 -0700 wip-dumpling-rados-xattr
2014-08-10 13:15:07 -0700 wip-8935
2014-08-11 16:00:20 -0700 wip-firefly-dmcrypt
2014-08-12 17:28:59 -0700 wip-firefly-dmcrypt-2
2014-08-12 20:48:54 -0700 wip-9073
2014-08-13 09:13:34 -0700 wip-9082-firefly
2014-08-15 09:33:40 -0700 wip-swat30
2014-08-15 14:29:11 -0700 wip-osd-mon-feature
2014-08-18 17:41:04 -0700 wip-snaps-firefly
2014-08-18 21:00:56 -0700 wip-snaps-dumpling
2014-08-26 16:57:27 -0700 wip-8639-a
2014-08-29 16:54:37 -0700 wip-9193
2014-08-31 17:46:33 -0700 wip-9309
2014-09-09 16:16:59 -0700 wip-9295
2014-09-12 18:11:42 -0700 wip-pidfile
2014-09-13 22:31:06 -0700 wip-9462
2014-09-16 21:36:15 -0700 wip-udev-el7
2014-09-21 19:16:02 -0700 wip-9487-dumpling-forcehack
2014-09-25 13:16:52 -0700 wip-9582-dumpling
2014-09-25 16:30:22 -0700 wip-noserver
2014-10-06 17:49:12 -0700 wip-9128
2014-10-07 10:15:27 -0700 wip-noserver-firefly
2014-10-10 16:48:14 -0700 wip-9706
2014-10-23 16:57:52 -0700 wip-promote-forward
2014-10-24 11:22:04 -0700 wip-osdc
2014-12-01 18:15:59 -0800 wip-10209
2014-12-02 11:03:44 -0800 wip-crush-straw-dumpling
2014-12-06 10:18:12 -0800 wip-10171
2014-12-06 11:49:06 -0800 wip-9485
2014-12-06 11:49:55 -0800 wip-9485-firefly
2014-12-07 08:56:03 -0800 wip-read-hole
2014-12-08 16:21:24 -0800 wip-9998
2014-12-09 13:32:00 -0800 wip-opcontext
2014-12-09 16:09:26 -0800 wip-crush-straw
2014-12-18 06:24:49 -0800 wip-osdmap-leak
2014-12-22 17:15:51 -0800 wip-10422-firefly
2014-12-23 15:49:49 -0800 wip-10372-firefly
2014-12-29 14:46:20 -0800 wip-sage-testing-firefly
2014-12-30 12:27:45 -0800 wip-10441
2015-01-09 11:01:18 -0800 wip-dho-sage
2015-01-12 08:30:40 -0800 emperor
2015-01-13 08:32:45 -0800 wip-formatter
2015-01-14 16:41:45 -0800 wip-10477
2015-01-19 18:15:12 -0800 wip-dho-old
2015-01-23 16:08:33 -0800 wip-10617
2015-01-27 18:45:25 -0800 wip-10458
2015-01-29 12:58:00 -0800 wip-mds-types
2015-02-02 02:46:10 -0800 wip-assert-version
2015-02-02 14:53:17 -0800 wip-crush-linear
2015-02-13 08:32:00 -0800 wip-crush-straw-firefly
2015-02-18 14:53:21 -0800 wip-ms-dump-on-send-giant
2015-02-23 13:32:23 -0800 wip-crushtool
2015-02-27 08:15:53 -0800 wip-build
2015-03-10 08:17:23 -0700 wip-add-cache
2015-03-16 09:32:22 -0700 wip-mon-doc
2015-03-16 09:43:59 -0700 wip-whiteout
2015-03-16 16:25:46 -0700 wip-7737-firefly
2015-03-19 17:39:02 -0700 wip-10759
2015-04-05 17:25:05 -0700 wip-9580
2015-04-06 13:50:03 -0700 wip-hammer
2015-04-09 13:30:48 -0700 wip-crush-straw2-div0-hammer
2015-04-11 08:48:06 -0700 wip-plugin
2015-04-28 14:51:16 -0700 wip-11493-b
2015-04-28 15:19:37 -0700 wip-11464
2015-04-28 17:31:31 -0700 wip-civetweb-openssl
2015-05-01 09:00:26 -0700 wip-hammer-snaps
2015-05-06 14:41:51 -0700 wip-fpie
2015-05-14 09:20:33 -0700 wip-11604-hammer
2015-05-14 15:32:41 -0400 wip-11622
2015-06-02 01:05:53 -0400 wip-newstore-debuglist
2015-06-03 21:02:30 -0400 wip-10873-firefly
2015-06-05 08:56:30 -0700 wip-rgw-civetweb-port
2015-06-06 00:05:26 -0400 wip-temp-base
2015-06-09 17:15:31 -0400 wip-promote-prob
2015-06-16 13:38:27 -0700 wip-chain-xattr-hammer
2015-06-17 11:35:18 -0700 wip-12064
2015-06-18 16:43:06 -0700 wip-user-old
2015-07-08 15:47:20 -0400 wip-mdscap-debug
2015-07-27 09:01:31 -0400 wip-12465-hammer
2015-07-31 08:51:02 -0400 wip-12551-hammer
2015-08-03 11:53:09 -0400 wip-12536
2015-08-04 13:21:50 -0400 wip-osd-compat-hammer
2015-08-10 09:56:16 -0400 wip-filestore-handle
2015-08-10 14:48:22 -0400 wip-perf
2015-08-11 16:16:55 -0400 wip-nocmtime
2015-08-12 14:19:08 -0400 wip-mdscap-test
2015-08-13 15:59:46 -0400 wip-buffer-alloc
2015-08-19 09:52:02 -0400 wip-12536-hammer
2015-08-25 16:40:25 -0400 wip-memcpy
2015-08-27 14:09:50 -0400 liewegas-wip-hammer-feature-hammer
2015-08-27 14:11:23 -0400 liewegas-wip-hammer-feature
2015-09-01 17:44:06 -0400 wip-corpus-hammer
2015-09-02 21:58:37 -0400 wip-5785
2015-09-03 14:23:11 -0400 wip-malloc
2015-09-04 15:59:34 -0400 wip-12966
2015-09-05 09:48:40 -0400 wip-post-file
2015-09-12 09:20:02 -0400 wip-10617-again
2015-09-24 11:38:41 -0400 wip-scrub-fix
2015-09-30 09:07:03 -0400 wip-13251
2015-10-01 08:55:17 -0400 wip-suse-spec-fixes
2015-10-06 10:54:50 -0400 wip-13379
2015-10-13 10:32:16 -0400 wip-ecpool-hammer
2015-10-13 17:32:43 -0400 loic-infernalis
2015-10-20 11:31:08 -0400 wip-mon-reset-features
2015-10-21 17:28:23 -0400 wip-newstore-frags
2015-10-22 09:17:03 -0400 wip-newstore-frags-recycle
2015-10-24 19:51:15 -0400 wip-sage-testing-infernalis
2015-12-06 09:24:17 -0500 wip-fix-buffer
2016-01-29 09:06:37 -0500 firefly
2016-01-30 08:57:36 -0500 wip-sage-testing-hammer
2016-02-01 15:56:27 -0500 wip-sage-testing-coverity
2016-02-23 19:30:51 -0500 wip-before-pkdgs-change
2016-03-17 12:58:54 -0400 wip-15073
2016-04-03 13:53:06 -0400 wip-rest-mds
2016-04-05 15:42:02 -0400 wip-legacy-layout-zero
2016-04-12 10:25:19 -0400 wip-15643
2016-04-30 17:12:05 -0400 wip-make-check
2016-05-06 08:41:46 -0400 wip-auth-infernalis
2016-05-11 09:26:38 -0400 wip-bigbang
2016-05-25 14:59:33 -0400 wip-osdmapcrc-hammer-0.94.6
2016-06-09 15:35:57 -0400 wip-bluestore-blobcache
2016-08-13 16:49:59 -0400 wip-bluestore-ceph-disk
2016-08-13 18:09:26 -0400 wip-hack-tolerate-missing-hitset-hammer
2016-10-03 14:42:35 -0400 wip-mgr-fix
2016-10-04 16:30:05 -0400 wip-denc
2016-10-05 15:19:11 -0400 wip-mon-stuck
2016-10-23 18:42:02 -0500 wip-sage-testing2
2016-11-02 09:37:50 -0400 wip-post-file-key-jewel
2016-11-10 09:36:45 -0500 wip-mistur
2016-11-11 16:12:38 -0500 wip-sage-testing
Samuel Just <sjust@redhat.com>
2015-05-14 15:10:08 -0700 wip-sam-working2
2016-05-02 15:50:35 -0700 wip-sam-testing-jewel
2016-06-10 16:22:36 -0700 wip-sam-jewel-testing
2016-06-20 11:40:51 -0700 wip-sam-testing
2016-07-06 13:22:57 -0700 wip-replica-read
2016-11-11 17:45:59 -0800 wip-sam-working
Somnath Roy <somnath.roy@sandisk.com>
2016-02-17 20:16:39 -0500 wip-make-shared
Syed Masum Billah <syed.masum.billah@gmail.com>
2015-10-07 11:43:14 -0400 wip-dmclock
Vasu Kulkarni <vasu@redhat.com>
2016-01-18 17:39:47 -0500 wip-13483-hammer
2016-07-15 13:40:29 -0700 wip-rbd-mirror
Venky Shankar <vshankar@redhat.com>
2016-11-03 08:53:55 +0530 wip-17356
2016-11-11 13:39:39 +0530 wip-ec-partial-overwrites
2016-11-13 21:50:52 +0530 wip-librbd-ec-support
Vicente Cheng <freeze.bilsted@gmail.com>
2016-03-09 00:20:54 +0800 pr-7977
Victor Araujo <ve.ar91@gmail.com>
2016-08-11 16:34:54 +0200 wip-blkin-10637
Warren Usui <warren.usui@inktank.com>
2014-09-10 16:04:49 -0700 wip-9425-wusui
Warren Usui <wusui@magna002.ceph.redhat.com>
2016-07-29 12:53:20 -0400 wip-openstack-wusui
Xiaoxi Chen <xiaoxchen@ebay.com>
2016-03-11 19:23:37 -0700 hammer-pr-8052
Yan, Zheng <zyan@redhat.com>
2015-01-26 14:58:30 +0800 wip-mds-shared-ptr
2016-09-29 19:03:21 +0800 wip-mds-multithread
2016-10-18 17:44:31 +0800 wip-zyan-testing
Yehuda Sadeh <yehuda@inktank.com>
2012-11-16 11:09:34 -0800 wip-mongoose
2013-02-28 09:56:43 -0800 wip-librados-exec
2013-03-22 11:29:49 -0700 wip-rgw-zone-3
2013-05-16 09:08:46 -0700 wip-5073-2
2013-06-29 00:25:32 -0700 wip-rgw-geo-2-replicalog2
2013-06-29 21:04:39 -0700 wip-rgw-geo-3
2013-07-08 18:55:19 -0700 rgw-next-libcurl
2013-08-15 11:00:05 -0700 wip-5978
2013-08-16 18:19:02 -0700 wip-rgw-papercuts
2013-10-07 09:45:20 -0700 wip-rgw-write
2013-10-17 21:29:34 -0700 wip-apache-mod
2013-10-30 10:31:11 -0700 wip-rgw-nxweb
2013-10-31 14:40:23 -0700 wip-bobtail-admin
2013-11-04 19:02:35 -0800 wip-rgw-standalone
2013-11-08 16:26:23 -0800 wip-6744
2013-12-07 21:13:19 -0800 wip-objecter-lock
2013-12-10 11:33:29 -0800 wip-mongoose-2
2013-12-13 11:01:49 -0800 wip-messenger-prefetch
2013-12-17 23:24:27 -0800 wip-rgw-getobj-cb
2013-12-18 12:57:40 -0800 wip-queueing3
2013-12-18 13:02:52 -0800 wip-queueing3-rgw
2014-01-09 18:22:46 -0800 wip-queuing3-loadgen
2014-01-15 13:06:31 -0800 wip-rgw-civetweb
2014-01-15 14:35:57 -0800 wip-user-quota
2014-01-28 09:38:19 -0800 bobtail
2014-01-28 09:40:18 -0800 cuttlefish
2014-02-05 21:51:11 -0800 wip-rgw-manifest
2014-02-20 09:25:04 -0800 multi-object-delete
2014-02-21 10:43:37 -0800 wip-messenger-prefetch2
2014-02-21 19:50:36 -0800 wip-rgw-server-changes
2014-02-26 14:00:01 -0800 wip-objecter-locking
2014-02-27 13:07:55 -0800 wip-rwmap
2014-03-07 17:15:39 -0800 wip-objecter-session-ops
2014-03-21 11:21:18 -0700 wip-rgw-fail
2014-03-25 14:08:01 -0700 wip-rgw-less-alloc
2014-04-03 13:46:16 -0700 wip-rgw-less-alloc-2
2014-04-17 16:38:32 -0700 wip-objecter-session-ops-4
2014-04-29 15:50:59 -0700 wip-objecter-session-ops-sage
2014-04-29 15:50:59 -0700 wip-objecter-session-ops-sage-old
2014-06-04 13:25:23 -0700 wip-objecter-yehuda
2014-07-14 10:50:48 -0700 wip-firefly-8698
Yehuda Sadeh <yehuda@redhat.com>
2014-07-25 13:53:26 -0700 wip-rgw-align-firefly
2014-08-22 10:05:53 -0700 wip-civetweb-log
2014-10-24 11:43:14 -0700 wip-rgw-explicit-reason
2014-11-10 23:37:34 -0800 wip-rgw-scrub-dumpling
2014-11-21 10:15:36 -0800 wip-watch-notify-rgw
2014-11-26 15:18:07 -0800 wip-proxy-fcgi-simple
2014-12-03 09:55:10 -0800 wip-firefly-9089
2014-12-09 09:58:57 -0800 wip-proxy-fcgi
2014-12-09 13:08:58 -0800 wip-crush-straw2-ln
2014-12-11 17:32:22 -0800 wip-rgw-versioning
2015-01-08 10:28:05 -0800 wip-bi-sharding
2015-01-08 11:46:15 -0800 wip-10482-firefly
2015-01-08 13:34:49 -0800 wip-bi-sharding-2
2015-01-16 09:12:54 -0800 wip-bi-sharding-3
2015-01-21 16:43:31 -0800 wip-rgw-versioning-3
2015-01-29 16:24:33 -0800 wip-rgw-versioning-4
2015-01-30 15:50:18 -0800 wip-10482
2015-02-05 15:37:43 -0800 wip-rgw-reason-dumpling
2015-02-10 17:21:39 -0800 wip-5073-3
2015-02-13 16:39:53 -0800 wip-10849
2015-02-18 08:54:23 -0800 wip-firefly-rgw-backports
2015-02-27 14:10:39 -0800 wip-dho-10965
2015-02-27 16:22:30 -0800 wip-rgw-owner
2015-02-27 17:13:21 -0800 wip-dho-owner
2015-02-27 17:14:17 -0800 wip-rgw-owner-firefly
2015-03-02 19:04:53 -0800 wip-dho
2015-03-03 11:03:35 -0800 wip-rgw-keystone-expire
2015-03-27 10:00:24 -0700 wip-rgw-mark
2015-04-16 15:54:34 -0700 wip-11416
2015-04-24 14:45:40 -0700 wip-rgw-content-length
2015-05-06 16:03:46 -0700 wip-hammer-replicalog
2015-05-21 10:19:21 -0700 wip-rgw-handles
2015-05-21 15:08:12 -0700 wip-rgw-orphans
2015-06-12 09:16:17 -0700 wip-rgw-noperiod
2015-07-23 23:06:28 -0700 wip-rgw-metaheap
2015-08-26 14:38:41 -0700 wip-11455
2015-08-31 14:10:26 -0700 wip-11455-firefly
2015-08-31 14:16:39 -0700 wip-12537-hammer
2015-08-31 14:17:05 -0700 wip-11455-hammer
2015-09-01 14:08:24 -0700 wip-12913
2015-09-10 17:53:01 -0700 wip-rgw-metaheap-2
2015-09-22 13:16:44 -0700 wip-rgw-slo
2015-09-22 15:49:27 -0700 wip-12958
2015-09-25 10:44:40 -0700 wip-13239
2015-09-29 08:18:32 -0700 wip-13239-infernalis
2015-09-29 11:04:35 -0700 wip-rgw-yehuda
2015-10-12 16:45:09 -0700 wip-static-website
2015-11-06 13:26:13 -0800 wip-12955
2015-11-09 15:24:29 -0800 revert-6419-wip-openssl
2015-12-02 10:45:42 -0800 wip-5073
2015-12-09 11:36:19 -0800 wip-rgw-lifecycle
2016-01-20 16:47:01 -0800 wip-rgw-aws4-int-2
2016-01-27 11:07:43 -0800 wip-rgw-static-website-yehuda
2016-01-28 16:01:40 -0800 wip-14549
2016-02-05 13:05:36 -0800 wip-14678-hammer
2016-02-09 14:21:00 -0800 wip-rgw-firstput-hammer
2016-02-16 08:26:20 -0800 wip-rgw-new-multisite-rebase-2
2016-02-18 13:29:44 -0800 wip-rgw-multisite-stream
2016-02-19 14:34:13 -0800 wip-rgw-aws4
2016-02-26 16:07:29 -0800 wip-rgw-usage
2016-03-03 13:56:37 -0800 wip-14975
2016-03-03 14:06:19 -0800 wip-rgw-indexless
2016-03-03 16:07:39 -0800 wip-rgw-payer-yehuda
2016-03-04 13:56:50 -0800 wip-librados-stat2-2
2016-03-04 15:53:29 -0800 wip-rgw-highres
2016-03-10 16:51:50 -0800 wip-14678
2016-03-12 20:07:04 -0800 revert-7985-rgw-token-7
2016-03-23 10:35:28 -0700 wip-rgw-sync-fixes-4
2016-04-15 14:12:05 -0700 wip-rgw-testing-yehudasa
2016-04-15 17:27:45 -0700 wip-rgw-testing-yehudasa-2
2016-04-19 06:11:09 -0700 wip-rgw-leak
2016-04-30 09:31:55 -0700 wip-rgw-leak-2
2016-05-04 16:34:49 -0700 wip-rgw-test
2016-05-05 14:10:01 -0700 wip-15745-hammer
2016-05-06 08:48:42 -0700 wip-15745
2016-05-06 10:10:17 -0700 wip-rgw-yehuda-test
2016-05-06 15:32:50 -0700 wip-rgw-test-fix
2016-05-09 14:38:22 -0700 wip-rgw-leak-3
2016-05-10 14:18:56 -0700 wip-rgw-jewel
2016-05-10 14:18:56 -0700 wip-rgw-jewel-2
2016-05-10 15:34:19 -0700 wip-rgw-leak-4
2016-05-18 17:21:28 -0700 wip-rgw-fix
2016-05-20 13:15:26 -0700 wip-yehuda-testing
2016-07-15 13:19:48 -0700 wip-rgw-testing-jewel
2016-07-20 15:47:09 -0700 wip-16742-jewel
2016-08-14 22:26:41 -0700 wip-rgw-yehuda-testing
2016-10-03 16:51:40 -0700 dnm-dang-reshard
2016-10-03 16:51:40 -0700 wip-orit-resharding-hammer
2016-10-03 16:51:40 -0700 wip-rgw-resharding-hammer
2016-10-19 08:41:50 -0700 wip-rgw-resharding
2016-10-20 12:30:49 -0700 wip-17635
2016-11-03 13:11:54 -0700 wip-civetweb-1.8
Yuan Zhou <yuan.zhou@intel.com>
2015-01-28 14:23:12 +0800 zhouyuan-submodule_https_git
2015-03-30 13:39:31 +0800 zhouyuan/isal_2.13
2015-08-12 09:09:07 +0800 wip-5072
Yuri Weinstein <yweinste@radhat.com>
2016-11-04 15:22:21 +0000 wip-yuri-testing2_2016_11_5
Yuri Weinstein <yweinste@redhat.com>
2016-09-27 16:10:07 +0000 wip-mon-forward_2016_09_27
Zhi Zhang <willzzhang@tencent.com>
2016-09-14 13:02:41 +0800 wip-pr-10135
Zhiqiang Wang <zhiqiang.wang@intel.com>
2015-06-18 09:07:42 +0800 wip-proxy-write
2015-06-18 16:50:08 +0800 wip-cache-pin
2015-09-02 11:20:12 +0800 wonzhq-rbd-write-full
2015-09-08 15:32:40 +0800 wonzhq-tmap-update
lavalake <lavalakewl@gmail.com>
2015-08-21 21:51:12 -0400 wip-rgw-google-api
markhpc <mark.nelson@inktank.com>
2013-11-06 09:23:22 -0600 wip-v0.70-mark
2014-03-17 14:50:57 -0500 wip-pq-mark
2014-07-29 18:53:37 -0500 wip-rocksdb-mark
root <root@rhs-cli-08.gdev.lab.eng.rdu2.redhat.com>
2016-11-14 10:49:25 -0500 rcu
xinxin shu <shuxinxin@chinac.com>
2016-09-28 11:52:58 +0800 wip-intel-testing
xinxin shu <xinxin.shu@intel.com>
2015-06-03 09:04:52 +0800 wip-lmdb
Grouped by committer, ordered by commit time stamp.
^ permalink raw reply
* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Auger Eric @ 2016-11-14 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114153149.GY2078@8bytes.org>
Hi Joerg,
On 14/11/2016 16:31, Joerg Roedel wrote:
> Hi Eric,
>
> On Fri, Nov 11, 2016 at 05:45:19PM +0100, Auger Eric wrote:
>> On 11/11/2016 17:22, Joerg Roedel wrote:
>>> So I think we need a way to tell userspace about the reserved regions
>>> (per iommu-group) so that userspace knows where it can not map anything,
>
>> Current plan is to expose that info through an iommu-group sysfs
>> attribute, as you and Robin advised.
>
> Great.
>
>>> and VFIO can enforce that. But the right struct here is not an
>>> iova-allocator rb-tree, a ordered linked list should be sufficient.
>> I plan a linked list to store the reserved regions (P2P regions, MSI
>> region, ...). get_dma_regions is called with a list local to a function
>> for that. Might be needed to move that list head in the iommu_group to
>> avoid calling the get_dm_regions again in the attribute show function?
>
> You can re-use the get_dm_regions() call-back available in the iommu-ops
> already. Just rename it and add a flag to it which tells the iommu-core
> whether that region needs to be mapped or not.
>
>> But to allocate the IOVAs within the MSI reserved region, I understand
>> you don't want us to use the iova.c allocator, is that correct? We need
>> an allocator though, even a very basic one based on bitmap or whatever.
>> There potentially have several different physical MSI frame pages to map.
>
> I don't get this, what do you need and address-allocator for?
There are potentially several MSI doorbell physical pages in the SOC
that are accessed through the IOMMU (translated). Each of those must
have a corresponding IOVA and IOVA/PA mapping programmed in the IOMMU.
Else MSI will fault.
- step 1 was to define a usable IOVA range for MSI mapping. So now we
decided the base address and size would be hardcoded for ARM. The
get_dm_region can be used to retrieve that hardcoded region.
- Step2 is to allocate IOVAs within that range and map then for each of
those MSI doorbells. This is done in the MSI controller compose() callback.
I hope I succeeded in clarifying this time.
Robin sent today a new version of its cookie think using a dummy
allocator. I am currently integrating it.
Thanks
Eric
>
>
>
> Joerg
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Auger Eric @ 2016-11-14 16:08 UTC (permalink / raw)
To: Joerg Roedel
Cc: drjones, alex.williamson, jason, kvm, marc.zyngier, punit.agrawal,
will.deacon, linux-kernel, diana.craciun, iommu,
pranav.sawargaonkar, christoffer.dall, tglx, robin.murphy,
linux-arm-kernel, eric.auger.pro
In-Reply-To: <20161114153149.GY2078@8bytes.org>
Hi Joerg,
On 14/11/2016 16:31, Joerg Roedel wrote:
> Hi Eric,
>
> On Fri, Nov 11, 2016 at 05:45:19PM +0100, Auger Eric wrote:
>> On 11/11/2016 17:22, Joerg Roedel wrote:
>>> So I think we need a way to tell userspace about the reserved regions
>>> (per iommu-group) so that userspace knows where it can not map anything,
>
>> Current plan is to expose that info through an iommu-group sysfs
>> attribute, as you and Robin advised.
>
> Great.
>
>>> and VFIO can enforce that. But the right struct here is not an
>>> iova-allocator rb-tree, a ordered linked list should be sufficient.
>> I plan a linked list to store the reserved regions (P2P regions, MSI
>> region, ...). get_dma_regions is called with a list local to a function
>> for that. Might be needed to move that list head in the iommu_group to
>> avoid calling the get_dm_regions again in the attribute show function?
>
> You can re-use the get_dm_regions() call-back available in the iommu-ops
> already. Just rename it and add a flag to it which tells the iommu-core
> whether that region needs to be mapped or not.
>
>> But to allocate the IOVAs within the MSI reserved region, I understand
>> you don't want us to use the iova.c allocator, is that correct? We need
>> an allocator though, even a very basic one based on bitmap or whatever.
>> There potentially have several different physical MSI frame pages to map.
>
> I don't get this, what do you need and address-allocator for?
There are potentially several MSI doorbell physical pages in the SOC
that are accessed through the IOMMU (translated). Each of those must
have a corresponding IOVA and IOVA/PA mapping programmed in the IOMMU.
Else MSI will fault.
- step 1 was to define a usable IOVA range for MSI mapping. So now we
decided the base address and size would be hardcoded for ARM. The
get_dm_region can be used to retrieve that hardcoded region.
- Step2 is to allocate IOVAs within that range and map then for each of
those MSI doorbells. This is done in the MSI controller compose() callback.
I hope I succeeded in clarifying this time.
Robin sent today a new version of its cookie think using a dummy
allocator. I am currently integrating it.
Thanks
Eric
>
>
>
> Joerg
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Re: [RFC 09/14] SoundWire: Add support to handle Slave status change
From: Charles Keepax @ 2016-11-14 16:08 UTC (permalink / raw)
To: Hardik Shah
Cc: alsa-devel, linux-kernel, tiwai, pierre-louis.bossart, broonie,
lgirdwood, plai, patches.audio, Sanyog Kale
In-Reply-To: <1477053673-16021-10-git-send-email-hardik.t.shah@intel.com>
On Fri, Oct 21, 2016 at 06:11:07PM +0530, Hardik Shah wrote:
> This patch adds the support for updating the Slave status to bus driver.
> Master driver updates Slave status change to the bus driver. Bus driver
> takes appropriate action on Slave status change like.
>
> 1. Registering new device if new Slave got enumerated on bus.
> 2. Assigning the device number to the Slave device
> 3. Marking Slave as un-attached if Slave got detached from bus.
> 4. Handling Slave alerts.
>
> Signed-off-by: Hardik Shah <hardik.t.shah@intel.com>
> Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> ---
> sound/sdw/sdw.c | 1074 ++++++++++++++++++++++++++++++++++++++++++++++++++
> sound/sdw/sdw_priv.h | 66 ++++
> 2 files changed, 1140 insertions(+)
>
<snip>
> +static int sdw_slv_register(struct sdw_master *mstr)
> +{
> + int ret, i;
> + struct sdw_msg msg;
> + u8 buf[SDW_NUM_DEV_ID_REGISTERS];
> + struct sdw_slave *sdw_slave;
> + int dev_num = -1;
> + bool found = false;
> +
> + /* Create message to read the 6 dev_id registers */
> + sdw_create_rd_msg(&msg, 0, SDW_SCP_DEVID_0, SDW_NUM_DEV_ID_REGISTERS,
> + buf, 0x0);
> +
> + /*
> + * Multiple Slaves may report an Attached_OK status as Device0.
> + * Since the enumeration relies on a hardware arbitration and is
> + * done one Slave at a time, a loop needs to run until all Slaves
> + * have been assigned a non-zero DeviceNumber. The loop exits when
> + * the reads from Device0 devID registers are no longer successful,
> + * i.e. there is no Slave left to enumerate
> + */
> + while ((ret = (snd_sdw_slave_transfer(mstr, &msg, SDW_NUM_OF_MSG1_XFRD))
> + == SDW_NUM_OF_MSG1_XFRD)) {
> +
> + /*
> + * Find is Slave is re-enumerating, and was already
> + * registered earlier.
> + */
> + found = sdw_find_slv(mstr, &msg, &dev_num);
> +
> + /*
> + * Reprogram the Slave device number if its getting
> + * re-enumerated. If that fails we continue finding new
> + * slaves, we flag error but don't stop since there may be
> + * new Slaves trying to get enumerated.
> + */
> + if (found) {
> + ret = sdw_program_dev_num(mstr, dev_num);
> + if (ret < 0)
> + dev_err(&mstr->dev, "Re-registering slave failed ret = %d", ret);
> +
> + continue;
> +
> + }
> +
> + /*
> + * Find the free device_number for the new Slave getting
> + * enumerated 1st time.
> + */
> + dev_num = sdw_find_free_dev_num(mstr, &msg);
> + if (dev_num < 0) {
> + dev_err(&mstr->dev, "Failed to find free dev_num ret = %d\n", ret);
> + goto dev_num_assign_fail;
> + }
> +
> + /*
> + * Allocate and initialize the Slave device on first
> + * enumeration
> + */
> + sdw_slave = kzalloc(sizeof(*sdw_slave), GFP_KERNEL);
> + if (!sdw_slave) {
> + ret = -ENOMEM;
> + goto mem_alloc_failed;
> + }
> +
> + /*
> + * Initialize the allocated Slave device, set bus type and
> + * device type to SoundWire.
> + */
> + sdw_slave->mstr = mstr;
> + sdw_slave->dev.parent = &sdw_slave->mstr->dev;
> + sdw_slave->dev.bus = &sdw_bus_type;
> + sdw_slave->dev.type = &sdw_slv_type;
> + sdw_slave->priv.addr = &mstr->sdw_addr[dev_num];
> + sdw_slave->priv.addr->slave = sdw_slave;
> +
> + for (i = 0; i < SDW_NUM_DEV_ID_REGISTERS; i++)
> + sdw_slave->priv.dev_id[i] = msg.buf[i];
> +
> + dev_dbg(&mstr->dev, "SDW slave slave id found with values\n");
> + dev_dbg(&mstr->dev, "dev_id0 to dev_id5: %x:%x:%x:%x:%x:%x\n",
> + msg.buf[0], msg.buf[1], msg.buf[2],
> + msg.buf[3], msg.buf[4], msg.buf[5]);
> + dev_dbg(&mstr->dev, "Dev number assigned is %x\n", dev_num);
> +
> + /*
> + * Set the Slave device name, its based on the dev_id and
> + * to bus which it is attached.
> + */
> + dev_set_name(&sdw_slave->dev, "sdw-slave%d-%02x:%02x:%02x:%02x:%02x:%02x",
> + sdw_master_get_id(mstr),
> + sdw_slave->priv.dev_id[0],
> + sdw_slave->priv.dev_id[1],
> + sdw_slave->priv.dev_id[2],
> + sdw_slave->priv.dev_id[3],
> + sdw_slave->priv.dev_id[4],
> + sdw_slave->priv.dev_id[5]);
> +
> + /*
> + * Set name based on dev_id. This will be used in match
> + * function to bind the device and driver.
> + */
> + sprintf(sdw_slave->priv.name, "%02x:%02x:%02x:%02x:%02x:%02x",
> + sdw_slave->priv.dev_id[0],
> + sdw_slave->priv.dev_id[1],
> + sdw_slave->priv.dev_id[2],
> + sdw_slave->priv.dev_id[3],
> + sdw_slave->priv.dev_id[4],
> + sdw_slave->priv.dev_id[5]);
> + ret = device_register(&sdw_slave->dev);
> + if (ret) {
> + dev_err(&mstr->dev, "Register slave failed ret = %d\n", ret);
> + goto reg_slv_failed;
> + }
There are some issues with this, as the slave driver only probes
when the device actually shows up on the bus. However often
(especially in embedded contexts) some things may need to be
done to enable the slave. For example it may be held in reset or
its power supplies switched off until they are need. As such it
generally helps if the device probe can be called before it shows
up on the bus, the device probe can then do the necessary actions
to enable the device at which point it will show up on the bus.
Thanks,
Charles
^ permalink raw reply
* Re: [upstream-release] [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
From: Scott Wood @ 2016-11-14 16:07 UTC (permalink / raw)
To: Sriram Dash, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: mark.rutland@arm.com, felipe.balbi@linux.intel.com,
mathias.nyman@intel.com, catalin.marinas@arm.com,
will.deacon@arm.com, kishon@ti.com, robh+dt@kernel.org,
stern@rowland.harvard.edu, Suresh Gupta,
gregkh@linuxfoundation.org, pku.leo@gmail.com
In-Reply-To: <1479101215-26954-2-git-send-email-sriram.dash@nxp.com>
On 11/13/2016 11:27 PM, Sriram Dash wrote:
> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> new file mode 100644
> index 0000000..d934c80
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> @@ -0,0 +1,36 @@
> +Driver for Freescale USB 3.0 PHY
> +
> +Required properties:
> +
> +- compatible : fsl,qoriq-usb3-phy
This is a very vague compatible. Are there versioning registers within
this register block?
> +/* Parameter control */
> +#define USB3PRM1CR 0x000
> +#define USB3PRM1CR_VAL 0x27672b2a
> +
> +/*
> + * struct qoriq_usb3_phy - driver data for USB 3.0 PHY
> + * @dev: pointer to device instance of this platform device
> + * @param_ctrl: usb3 phy parameter control register base
> + * @phy_base: usb3 phy register memory base
> + * @has_erratum_flag: keeps track of erratum applicable on device
> + */
> +struct qoriq_usb3_phy {
> + struct device *dev;
> + void __iomem *param_ctrl;
> + void __iomem *phy_base;
> + u32 has_erratum_flag;
> +};
> +
> +static inline u32 qoriq_usb3_phy_readl(void __iomem *addr, u32 offset)
> +{
> + return __raw_readl(addr + offset);
> +}
> +
> +static inline void qoriq_usb3_phy_writel(void __iomem *addr, u32 offset,
> + u32 data)
> +{
> + __raw_writel(data, addr + offset);
> +}
Why raw? Besides missing barriers, this will cause the accesses to be
native-endian which is not correct.
> +/*
> + * Erratum A008751
> + * SCFG USB3PRM1CR has incorrect default value
> + * SCFG USB3PRM1CR reset value should be 32'h27672B2A instead of 32'h25E72B2A.
When documenting C code, can you stick with C-style numeric constants?
For that matter, just put the constant in the code instead of hiding it
in an overly-generically-named USB3PRM1CR_VAL and then you won't need to
redundantly state the value in a comment. Normally putting magic
numbers in symbolic constants is a good thing, but in this case it's not
actually describing anything and the number is of no meaning outside of
this one erratum workaround (it might even be a different value if
another chip has a similar erratum).
> + */
> +static void erratum_a008751(struct qoriq_usb3_phy *phy)
> +{
> + qoriq_usb3_phy_writel(phy->param_ctrl, USB3PRM1CR,
> + USB3PRM1CR_VAL);
> +}
> +
> +/*
> + * qoriq_usb3_phy_erratum - List of phy erratum
> + * @qoriq_phy_erratum - erratum application
> + * @compat - comapt string for erratum
> + */
> +
> +struct qoriq_usb3_phy_erratum {
> + void (*qoriq_phy_erratum)(struct qoriq_usb3_phy *phy);
> + char *compat;
> +};
> +
> +/* Erratum list */
> +struct qoriq_usb3_phy_erratum phy_erratum_tbl[] = {
> + {&erratum_a008751, "fsl,usb-erratum-a008751"},
> + /* Add init time erratum here */
> +};
This needs to be static.
Unnecessary & on the function pointer.
> +static int qoriq_usb3_phy_init(struct phy *x)
> +{
> + struct qoriq_usb3_phy *phy = phy_get_drvdata(x);
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(phy_erratum_tbl); i++)
> + if (phy->has_erratum_flag & 1 << i)
> + phy_erratum_tbl[i].qoriq_phy_erratum(phy);
> + return 0;
> +}
> +
> +static const struct phy_ops ops = {
> + .init = qoriq_usb3_phy_init,
> + .owner = THIS_MODULE,
> +};
> +
> +static int qoriq_usb3_phy_probe(struct platform_device *pdev)
> +{
> + struct qoriq_usb3_phy *phy;
> + struct phy *generic_phy;
> + struct phy_provider *phy_provider;
> + const struct of_device_id *of_id;
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + int i, ret;
> +
> + phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
> + if (!phy)
> + return -ENOMEM;
> + phy->dev = dev;
> +
> + of_id = of_match_device(dev->driver->of_match_table, dev);
> + if (!of_id) {
> + dev_err(dev, "failed to get device match\n");
> + ret = -EINVAL;
> + goto err_out;
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "param_ctrl");
> + if (!res) {
> + dev_err(dev, "failed to get param_ctrl memory\n");
> + ret = -ENOENT;
> + goto err_out;
> + }
> +
> + phy->param_ctrl = devm_ioremap_resource(dev, res);
> + if (!phy->param_ctrl) {
> + dev_err(dev, "failed to remap param_ctrl memory\n");
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy_base");
> + if (!res) {
> + dev_err(dev, "failed to get phy_base memory\n");
> + ret = -ENOENT;
> + goto err_out;
> + }
> +
> + phy->phy_base = devm_ioremap_resource(dev, res);
> + if (!phy->phy_base) {
> + dev_err(dev, "failed to remap phy_base memory\n");
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + phy->has_erratum_flag = 0;
> + for (i = 0; i < ARRAY_SIZE(phy_erratum_tbl); i++)
> + phy->has_erratum_flag |= device_property_read_bool(dev,
> + phy_erratum_tbl[i].compat) << i;
I don't see the erratum property in either the binding or the device
tree. Also, a property name is not a "compat".
Is there a reason why this flag and array mechanism is needed, rather
than just checking the erratum properties from the init function -- or,
if you have a good reason to not want to do device tree accesses from
init, just using a bool per erratum? How many errata are you expecting?
-Scott
^ permalink raw reply
* [upstream-release] [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
From: Scott Wood @ 2016-11-14 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479101215-26954-2-git-send-email-sriram.dash@nxp.com>
On 11/13/2016 11:27 PM, Sriram Dash wrote:
> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> new file mode 100644
> index 0000000..d934c80
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> @@ -0,0 +1,36 @@
> +Driver for Freescale USB 3.0 PHY
> +
> +Required properties:
> +
> +- compatible : fsl,qoriq-usb3-phy
This is a very vague compatible. Are there versioning registers within
this register block?
> +/* Parameter control */
> +#define USB3PRM1CR 0x000
> +#define USB3PRM1CR_VAL 0x27672b2a
> +
> +/*
> + * struct qoriq_usb3_phy - driver data for USB 3.0 PHY
> + * @dev: pointer to device instance of this platform device
> + * @param_ctrl: usb3 phy parameter control register base
> + * @phy_base: usb3 phy register memory base
> + * @has_erratum_flag: keeps track of erratum applicable on device
> + */
> +struct qoriq_usb3_phy {
> + struct device *dev;
> + void __iomem *param_ctrl;
> + void __iomem *phy_base;
> + u32 has_erratum_flag;
> +};
> +
> +static inline u32 qoriq_usb3_phy_readl(void __iomem *addr, u32 offset)
> +{
> + return __raw_readl(addr + offset);
> +}
> +
> +static inline void qoriq_usb3_phy_writel(void __iomem *addr, u32 offset,
> + u32 data)
> +{
> + __raw_writel(data, addr + offset);
> +}
Why raw? Besides missing barriers, this will cause the accesses to be
native-endian which is not correct.
> +/*
> + * Erratum A008751
> + * SCFG USB3PRM1CR has incorrect default value
> + * SCFG USB3PRM1CR reset value should be 32'h27672B2A instead of 32'h25E72B2A.
When documenting C code, can you stick with C-style numeric constants?
For that matter, just put the constant in the code instead of hiding it
in an overly-generically-named USB3PRM1CR_VAL and then you won't need to
redundantly state the value in a comment. Normally putting magic
numbers in symbolic constants is a good thing, but in this case it's not
actually describing anything and the number is of no meaning outside of
this one erratum workaround (it might even be a different value if
another chip has a similar erratum).
> + */
> +static void erratum_a008751(struct qoriq_usb3_phy *phy)
> +{
> + qoriq_usb3_phy_writel(phy->param_ctrl, USB3PRM1CR,
> + USB3PRM1CR_VAL);
> +}
> +
> +/*
> + * qoriq_usb3_phy_erratum - List of phy erratum
> + * @qoriq_phy_erratum - erratum application
> + * @compat - comapt string for erratum
> + */
> +
> +struct qoriq_usb3_phy_erratum {
> + void (*qoriq_phy_erratum)(struct qoriq_usb3_phy *phy);
> + char *compat;
> +};
> +
> +/* Erratum list */
> +struct qoriq_usb3_phy_erratum phy_erratum_tbl[] = {
> + {&erratum_a008751, "fsl,usb-erratum-a008751"},
> + /* Add init time erratum here */
> +};
This needs to be static.
Unnecessary & on the function pointer.
> +static int qoriq_usb3_phy_init(struct phy *x)
> +{
> + struct qoriq_usb3_phy *phy = phy_get_drvdata(x);
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(phy_erratum_tbl); i++)
> + if (phy->has_erratum_flag & 1 << i)
> + phy_erratum_tbl[i].qoriq_phy_erratum(phy);
> + return 0;
> +}
> +
> +static const struct phy_ops ops = {
> + .init = qoriq_usb3_phy_init,
> + .owner = THIS_MODULE,
> +};
> +
> +static int qoriq_usb3_phy_probe(struct platform_device *pdev)
> +{
> + struct qoriq_usb3_phy *phy;
> + struct phy *generic_phy;
> + struct phy_provider *phy_provider;
> + const struct of_device_id *of_id;
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + int i, ret;
> +
> + phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
> + if (!phy)
> + return -ENOMEM;
> + phy->dev = dev;
> +
> + of_id = of_match_device(dev->driver->of_match_table, dev);
> + if (!of_id) {
> + dev_err(dev, "failed to get device match\n");
> + ret = -EINVAL;
> + goto err_out;
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "param_ctrl");
> + if (!res) {
> + dev_err(dev, "failed to get param_ctrl memory\n");
> + ret = -ENOENT;
> + goto err_out;
> + }
> +
> + phy->param_ctrl = devm_ioremap_resource(dev, res);
> + if (!phy->param_ctrl) {
> + dev_err(dev, "failed to remap param_ctrl memory\n");
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy_base");
> + if (!res) {
> + dev_err(dev, "failed to get phy_base memory\n");
> + ret = -ENOENT;
> + goto err_out;
> + }
> +
> + phy->phy_base = devm_ioremap_resource(dev, res);
> + if (!phy->phy_base) {
> + dev_err(dev, "failed to remap phy_base memory\n");
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + phy->has_erratum_flag = 0;
> + for (i = 0; i < ARRAY_SIZE(phy_erratum_tbl); i++)
> + phy->has_erratum_flag |= device_property_read_bool(dev,
> + phy_erratum_tbl[i].compat) << i;
I don't see the erratum property in either the binding or the device
tree. Also, a property name is not a "compat".
Is there a reason why this flag and array mechanism is needed, rather
than just checking the erratum properties from the init function -- or,
if you have a good reason to not want to do device tree accesses from
init, just using a bool per erratum? How many errata are you expecting?
-Scott
^ permalink raw reply
* DomU application crashes while mmap'ing device memory on x86_64
From: Oleksandr Andrushchenko @ 2016-11-14 16:07 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 5840 bytes --]
Hi, there!
Sorry for the long read ahead, but it seems I've got stuck...
I am working on a PV driver and facing an mmap issue.
This actually happens when user-space tries to mmap
the memory allocated by the driver:
cma_obj->vaddr = dma_alloc_wc(drm->dev, size, &cma_obj->paddr,
GFP_KERNEL | __GFP_NOWARN);
and maping:
vma->vm_flags &= ~VM_PFNMAP;
vma->vm_pgoff = 0;
ret = dma_mmap_wc(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
cma_obj->paddr, vma->vm_end - vma->vm_start);
Return of the dma_mmap_wc is 0, but I see in the DomU kernel logs:
Nov 14 10:30:18 DomU kernel: [ 1169.569909] ------------[ cut here
]------------
Nov 14 10:30:18 DomU kernel: [ 1169.569911] WARNING: CPU: 1 PID: 5146 at
/home/kernel/COD/linux/arch/x86/xen/multicalls.c:129
xen_mc_flush+0x19c/0x1b0
Nov 14 10:30:18 DomU kernel: [ 1169.569912] Modules linked in:
xen_drmfront(OE) drm_kms_helper(OE) drm(OE) fb_sys_fops syscopyarea
sysfillrect sysimgblt crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
aesni_intel aes_x86_64 lrw glue_helper ablk_helper cryptd intel_rapl_perf
autofs4 [last unloaded: xen_drmfront]
Nov 14 10:30:18 DomU kernel: [ 1169.569919] CPU: 1 PID: 5146 Comm:
lt-modetest Tainted: G W OE 4.9.0-040900rc3-generic #201610291831
Nov 14 10:30:18 DomU kernel: [ 1169.569920] ffffc900406ffb10
ffffffff81416bf2 0000000000000000 0000000000000000
Nov 14 10:30:18 DomU kernel: [ 1169.569923] ffffc900406ffb50
ffffffff8108361b 00000081406ffb30 ffff88003f90b8e0
Nov 14 10:30:18 DomU kernel: [ 1169.569925] 0000000000000001
0000000000000010 0000000000000000 0000000000000201
Nov 14 10:30:18 DomU kernel: [ 1169.569928] Call Trace:
Nov 14 10:30:18 DomU kernel: [ 1169.569930] [<ffffffff81416bf2>]
dump_stack+0x63/0x81
Nov 14 10:30:18 DomU kernel: [ 1169.569932] [<ffffffff8108361b>]
__warn+0xcb/0xf0
Nov 14 10:30:18 DomU kernel: [ 1169.569934] [<ffffffff8108374d>]
warn_slowpath_null+0x1d/0x20
Nov 14 10:30:18 DomU kernel: [ 1169.569936] [<ffffffff8101d60c>]
xen_mc_flush+0x19c/0x1b0
Nov 14 10:30:18 DomU kernel: [ 1169.569938] [<ffffffff8101d716>]
__xen_mc_entry+0xf6/0x150
Nov 14 10:30:18 DomU kernel: [ 1169.569940] [<ffffffff81020476>]
xen_extend_mmu_update+0x56/0xd0
Nov 14 10:30:18 DomU kernel: [ 1169.569942] [<ffffffff81021d67>]
xen_set_pte_at+0x177/0x2f0
Nov 14 10:30:18 DomU kernel: [ 1169.569944] [<ffffffff811e064b>]
remap_pfn_range+0x30b/0x430
Nov 14 10:30:18 DomU kernel: [ 1169.569946] [<ffffffff815a8267>]
dma_common_mmap+0x87/0xa0
Nov 14 10:30:18 DomU kernel: [ 1169.569953] [<ffffffffc00ffa8f>]
drm_gem_cma_mmap_obj+0x8f/0xa0 [drm]
Nov 14 10:30:18 DomU kernel: [ 1169.569960] [<ffffffffc00ffac5>]
drm_gem_cma_mmap+0x25/0x30 [drm]
Nov 14 10:30:18 DomU kernel: [ 1169.569962] [<ffffffff811e79b5>]
mmap_region+0x3a5/0x640
Nov 14 10:30:18 DomU kernel: [ 1169.569964] [<ffffffff811e8096>]
do_mmap+0x446/0x530
Nov 14 10:30:18 DomU kernel: [ 1169.569966] [<ffffffff813b88b5>] ?
common_mmap+0x45/0x50
Nov 14 10:30:18 DomU kernel: [ 1169.569968] [<ffffffff813b8906>] ?
apparmor_mmap_file+0x16/0x20
Nov 14 10:30:18 DomU kernel: [ 1169.569970] [<ffffffff81377a5d>] ?
security_mmap_file+0xdd/0xf0
Nov 14 10:30:18 DomU kernel: [ 1169.569972] [<ffffffff811c8faa>]
vm_mmap_pgoff+0xba/0xf0
Nov 14 10:30:18 DomU kernel: [ 1169.569974] [<ffffffff811e5c01>]
SyS_mmap_pgoff+0x1c1/0x290
Nov 14 10:30:18 DomU kernel: [ 1169.569976] [<ffffffff8103313b>]
SyS_mmap+0x1b/0x30
Nov 14 10:30:18 DomU kernel: [ 1169.569978] [<ffffffff8188bbbb>]
entry_SYSCALL_64_fastpath+0x1e/0xad
Nov 14 10:30:18 DomU kernel: [ 1169.569979] ---[ end trace ce1796cb265ebe08
]---
Nov 14 10:30:18 DomU kernel: [ 1169.569982] ------------[ cut here
]------------
And output of xl dmesg says:
(XEN) memory.c:226:d0v0 Could not allocate order=9 extent: id=31
memflags=0x40 (488 of 512)
(d31) mapping kernel into physical memory
(d31) about to get started...
(XEN) d31 attempted to change d31v0's CR4 flags 00000620 -> 00040660
(XEN) d31 attempted to change d31v1's CR4 flags 00000620 -> 00040660
(XEN) traps.c:3657: GPF (0000): ffff82d0801a1a09 -> ffff82d08024b970
(XEN) mm.c:1893:d31v0 Bad L1 flags 90
(XEN) mm.c:1893:d31v0 Bad L1 flags 90
(XEN) mm.c:1893:d31v0 Bad L1 flags 90
(XEN) mm.c:1893:d31v0 Bad L1 flags 90
My setup is a little bit tricky... I am using a Xen setup running
inside VirtualBox:
1. xl info:
host : Dom0
release : 4.4.0-45-generic
version : #66-Ubuntu SMP Wed Oct 19 14:12:37 UTC 2016
machine : x86_64
nr_cpus : 2
max_cpu_id : 1
nr_nodes : 1
cores_per_socket : 2
threads_per_core : 1
cpu_mhz : 3408
hw_caps :
178bfbff:d6d82203:28100800:00000121:00000000:00842000:00000000:00000100
virt_caps :
total_memory : 2047
free_memory : 11
sharing_freed_memory : 0
sharing_used_memory : 0
outstanding_claims : 0
free_cpus : 0
xen_major : 4
xen_minor : 8
xen_extra : .0-rc
xen_version : 4.8.0-rc
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p
xen_scheduler : credit
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset :
xen_commandline : placeholder
cc_compiler : gcc (Debian 6.2.0-10) 6.2.0 20161027
cc_compile_by : ijackson
cc_compile_domain : chiark.greenend.org.uk
cc_compile_date : Tue Nov 1 18:11:16 UTC 2016
build_id : 3744fa5e7a5b01a0439ba4413e41a7a1c505d5ee
xend_config_format : 4
2. DomU
Linux DomU 4.9.0-040900rc3-generic #201610291831 SMP Sat Oct 29 22:32:46
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Could anyone please give me any hint on what needs to
be checked and how this can be resolved?
Thank you,
Oleksandr Andrushchenko
[-- Attachment #1.2: Type: text/html, Size: 7597 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [qemu-mainline test] 102209: regressions - FAIL
From: osstest service owner @ 2016-11-14 16:07 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Attachment #1: Type: text/plain, Size: 9998 bytes --]
flight 102209 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102209/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 101909
test-amd64-amd64-xl-qcow2 9 debian-di-install fail REGR. vs. 101909
test-amd64-i386-libvirt 11 guest-start fail REGR. vs. 101909
test-amd64-amd64-libvirt-vhd 9 debian-di-install fail REGR. vs. 101909
test-amd64-amd64-libvirt-xsm 11 guest-start fail REGR. vs. 101909
test-amd64-i386-libvirt-pair 20 guest-start/debian fail REGR. vs. 101909
test-amd64-i386-libvirt-xsm 11 guest-start fail REGR. vs. 101909
test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail REGR. vs. 101909
test-amd64-amd64-libvirt-pair 20 guest-start/debian fail REGR. vs. 101909
test-armhf-armhf-libvirt-raw 9 debian-di-install fail REGR. vs. 101909
test-armhf-armhf-xl-vhd 9 debian-di-install fail REGR. vs. 101909
test-armhf-armhf-libvirt-xsm 11 guest-start fail REGR. vs. 101909
test-armhf-armhf-libvirt 11 guest-start fail REGR. vs. 101909
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101909
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 101909
test-amd64-amd64-xl-rtds 9 debian-install fail like 101909
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass
version targeted for testing:
qemuu 83c83f9a5266ff113060f887f106a47920fa6974
baseline version:
qemuu 199a5bde46b0eab898ab1ec591f423000302569f
Last test of basis 101909 2016-11-03 23:21:40 Z 10 days
Failing since 101943 2016-11-04 22:40:48 Z 9 days 18 attempts
Testing same since 102163 2016-11-12 17:17:54 Z 1 days 5 attempts
------------------------------------------------------------
People who touched revisions under test:
ann.zhuangyanying@huawei.com
Christian Borntraeger <borntraeger@de.ibm.com>
Cornelia Huck <cornelia.huck@de.ibm.com>
Doug Evans <dje@google.com>
Eric Blake <eblake@redhat.com>
Fam Zheng <famz@redhat.com>
Gerd Hoffmann <kraxel@redhat.com>
John Snow <jsnow@redhat.com>
Julian Brown <julian@codesourcery.com>
Kevin Wolf <kwolf@redhat.com>
Li Qiang <liqiang6-s@360.cn>
Marc-André Lureau <marcandre.lureau@redhat.com>
Marcin Krzeminski <marcin.krzeminski@nokia.com>
Max Reitz <mreitz@redhat.com>
Michael Tokarev <mjt@tls.msk.ru>
Olaf Hering <olaf@aepfle.de>
Paolo Bonzini <pbonzini@redhat.com>
Peter Korsgaard <peter@korsgaard.com>
Peter Maydell <peter.maydell@linaro.org>
Prasad J Pandit <pjp@fedoraproject.org>
Samuel Thibault <samuel.thibault@ens-lyon.org>
Sander Eikelenboom <linux@eikelenboom.it>
Stefan Hajnoczi <stefanha@redhat.com>
Stefano Stabellini <sstabellini@kernel.org>
Thomas Huth <thuth@redhat.com>
Wei Liu <wei.liu2@citrix.com>
ZhuangYanying <ann.zhuangyanying@huawei.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm fail
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm fail
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt fail
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt fail
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair fail
test-amd64-i386-libvirt-pair fail
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 fail
test-amd64-amd64-xl-qcow2 fail
test-armhf-armhf-libvirt-raw fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd fail
test-armhf-armhf-xl-vhd fail
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 721 lines long.)
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"
From: Sharma, Shashank @ 2016-11-14 16:07 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Jose Abreu, Jia, Lin A, Akashdeep Sharma, Emil Velikov, dri-devel,
Daniel Vetter, Jim Bride
In-Reply-To: <20161114154937.GY31595@intel.com>
Regards
Shashank
On 11/14/2016 9:19 PM, Ville Syrjälä wrote:
> On Mon, Nov 14, 2016 at 08:14:34PM +0530, Sharma, Shashank wrote:
>> Regards
>> Shashank
>>> the revert:
>>>
>>> HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 700mm x 390mm
>>> - 1920x1080 60.00*+
>>> - 1920x1080i 60.00 50.00
>>> + 1920x1080 60.00*+ 50.00 59.94 30.00 25.00 24.00 29.97 23.98
>>> + 1920x1080i 60.00 50.00 59.94
>>> 1600x1200 60.00
>>> 1680x1050 59.88
>>> 1280x1024 75.02 60.02
>>> @@ -13,30 +13,29 @@
>>> 1360x768 60.02
>>> 1280x800 59.91
>>> 1152x864 75.00
>>> - 1280x720 60.00 50.00
>>> + 1280x720 60.00 50.00 59.94
>>> 1024x768 75.03 70.07 60.00
>>> 832x624 74.55
>>> 800x600 72.19 75.00 60.32
>>> - 640x480 75.00 72.81 66.67 59.94
>>> + 720x576 50.00
>>> + 720x480 60.00 59.94
>>> + 640x480 75.00 72.81 66.67 60.00 59.94
>>> 720x400 70.08
>> None of these aspect ratios are new modes / new aspect ratios from HDMI
>> 2.0/CEA-861-F
>> These are the existing modes, and should be independent of reverted
>> patches.
> They're affected because your patches changed them by adding the aspect
> ratio flags to them.
Yes, But they are independent of reverted patch, which adds aspect ratio
for HDMI 2.0 ratios (64:27 and 256:135)
>>> This was with sna, which does this:
>>> #define KNOWN_MODE_FLAGS ((1<<14)-1)
>>> if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
>>> mode->status = MODE_BAD; /* unknown flags => unhandled */
>>> so all the modes with an aspect ratio just vanished.
>>>
>>> -modesetting and -ati on the other hand just copy over the unknown
>>> bits into the xrandr mode structure, which sounds dubious at best:
>>> mode->Flags = kmode->flags; //& FLAG_BITS;
>>> I've not checked what damage it can actually cause.
>>>
>>>
>>> It looks like a few modes disappeared from the kernel's mode list
>>> as well, presumably because some cea modes in the list originated from
>>> DTDs and whanot so they don't have an aspect ratio and that causes
>>> add_alternate_cea_modes() to ignore them. So not populating an aspect
>>> ratio for cea modes originating from a source other than
>>> edid_cea_modes[] looks like another bug to me as well.
>> I am writing a patch series to cap the aspect ratio implementation under
>> a drm_cap_hdmi2_aspect_ratios
>> This is how its going to work (inspired from the 2D/stereo series from
>> damien L)
>>
>> - Add a new capability hdmi2_ar
> It should be just a generic "expose aspect ratio flags to userspace?"
Makes sense, in this way we can even revert the aspect_ratio property
for HDMI connector, as discussed during
the code review sessions of this patch series. In this way, when kernel
will expose the aspect ratios, it will either
do the aspect ratios as per EDID, or wont.
>
>> - by default parsing the new hdmi 2.0 aspect ratio will be disabled
>> under check of this cap
>> - during bootup time, while initializing the display, a userspace can
>> get_cap on the hdmi2_aspect_ratio
>> - If it wants HDMI 2.0 aspect ratio support, it will set the cap, and
>> kernel will expose these aspect ratios
>>> Another bug I think might be the ordering of the modes with aspect ratio
>>> specified. IIRC the spec says that the preferred aspect ratio should be
>>> listed first in the EDID, but I don't think we preserve that ordering
>>> in the final mode list. I guess we could fix that by somehow noting
>>> which aspect ratio is preferred and sort based on that, or we try to
>>> preserve the order from the EDID until we're ready to sort, and then do
>>> the sorting with a stable algorithm.
>> AFAIK The mode order and priority is decided and arranged in userspace,
>> based on various factors like
>> - preferred mode.
>> - previously applied mode in previous sessions (like for android tvs)
>> - Bigger h/w vs better refresh rate ?
>> - Xserver applies its own algorithms to decide which mode should be
>> shown first.
> Xorg does sort on its own. But since it doesn't know anything about
> aspect ratios and whatnot I wouldn't rely on that for anything. I
> also wouldn't expect eg. wayland compositors to do their own sorting.
> And yeah, looks like weston at least doesn't do any sorting whatsoever.
>
>> I dont think kernel needs to bother about it.
> So I'm going to say that we in fact do need to bother.
>
IMHO, making policies for UI is not a part of kernel design, a UI
manager (Hardware composed, X or Wayland) should take care of it, as
they have access to much information (Like previously applied mode, user
preference etc). When it comes to sorting of modes, the only general rule
across drivers like FB, V4L2, I have seen is the first mode in the list
should be preferred mode, which we are still keeping. And after that our
probed_modes were
anyways not sorted now, so it doesn't matter further.
If X server doesn't know what to do with aspect ratio flags, it can
chose not to set the cap, and if HWC knows, it can chose to set. This is
the same situation as 2D stereo modes
which are existing already.
Regards
Shashank
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] libsepol: fix checkpolicy dontaudit compiler bug
From: Stephen Smalley @ 2016-11-14 16:07 UTC (permalink / raw)
To: selinux
In-Reply-To: <1479139145-32596-1-git-send-email-sds@tycho.nsa.gov>
On 11/14/2016 10:59 AM, Stephen Smalley wrote:
> The combining logic for dontaudit rules was wrong, causing
> a dontaudit A B:C *; rule to be clobbered by a dontaudit A B:C p;
> rule.
>
> Reported-by: Nick Kralevich <nnk@google.com>
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Sorry, that's not correct either. NAKing my own patch.
> ---
> libsepol/src/expand.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/libsepol/src/expand.c b/libsepol/src/expand.c
> index 004a029..cdfb792 100644
> --- a/libsepol/src/expand.c
> +++ b/libsepol/src/expand.c
> @@ -1850,10 +1850,7 @@ static int expand_avrule_helper(sepol_handle_t * handle,
> */
> avdatump->data &= cur->data;
> } else if (specified & AVRULE_DONTAUDIT) {
> - if (avdatump->data)
> - avdatump->data &= ~cur->data;
> - else
> - avdatump->data = ~cur->data;
> + avdatump->data &= ~cur->data;
> } else if (specified & AVRULE_XPERMS) {
> xperms = avdatump->xperms;
> if (!xperms) {
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.