from:"Felipe Balbi"

Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

2020-09-10 Thread Felipe Balbi

Hi,

Joe Perches  writes:
>  drivers/usb/dwc3/core.c   |  2 +-
>  drivers/usb/gadget/legacy/inode.c |  2 +-
>  drivers/usb/gadget/udc/pxa25x_udc.c   |  4 ++--
>  drivers/usb/phy/phy-fsl-usb.c |  2 +-

for the drivers above:

Acked-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] usb: cdns3: gadget: Replace trace_printk by dev_dbg

2020-07-24 Thread Felipe Balbi

Nicolas Boichat  writes:

> On Thu, Jul 23, 2020 at 9:17 PM Felipe Balbi  wrote:
>>
>> Nicolas Boichat  writes:
>>
>> > trace_printk should not be used in production code, replace it
>> > call with dev_dbg.
>> >
>> > Signed-off-by: Nicolas Boichat 
>> >
>> > ---
>> >
>> > Unclear why a trace_printk was used in the first place, it's
>> > possible that some rate-limiting is necessary here.
>> >
>> >  drivers/usb/cdns3/gadget.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
>> > index 5e24c2e57c0d8c8..c303ab7c62d1651 100644
>> > --- a/drivers/usb/cdns3/gadget.c
>> > +++ b/drivers/usb/cdns3/gadget.c
>> > @@ -421,7 +421,7 @@ static int cdns3_start_all_request(struct cdns3_device 
>> > *priv_dev,
>> >   if ((priv_req->flags & REQUEST_INTERNAL) ||
>> >   (priv_ep->flags & EP_TDLCHK_EN) ||
>> >   priv_ep->use_streams) {
>> > - trace_printk("Blocking external request\n");
>> > + dev_dbg(priv_dev->dev, "Blocking external 
>> > request\n");
>>
>> Instead, I would suggest adding a proper trace event here; one that
>> includes "priv_ep->flags" in the output.
>
> The patch was already merged by Greg
> (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/usb/cdns3/gadget.c?id=b3a5ce874c2619c9b8a6c5bbcfefdb95e0227600),
> but feel free to do that as a follow-up CL.
>
> Looks like Peter -- the main author, is ok with dev_dbg (also,
> apologies for missing the R-b tag when I sent a v2 -- which is the one
> that was merged by Greg).

That's okay, we can get a proper trace event for v5.10. Maybe Pawel or
Roger would like to take the effort?

-- 
balbi


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] usb: cdns3: gadget: Replace trace_printk by dev_dbg

2020-07-23 Thread Felipe Balbi

Nicolas Boichat  writes:

> trace_printk should not be used in production code, replace it
> call with dev_dbg.
>
> Signed-off-by: Nicolas Boichat 
>
> ---
>
> Unclear why a trace_printk was used in the first place, it's
> possible that some rate-limiting is necessary here.
>
>  drivers/usb/cdns3/gadget.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
> index 5e24c2e57c0d8c8..c303ab7c62d1651 100644
> --- a/drivers/usb/cdns3/gadget.c
> +++ b/drivers/usb/cdns3/gadget.c
> @@ -421,7 +421,7 @@ static int cdns3_start_all_request(struct cdns3_device 
> *priv_dev,
>   if ((priv_req->flags & REQUEST_INTERNAL) ||
>   (priv_ep->flags & EP_TDLCHK_EN) ||
>   priv_ep->use_streams) {
> - trace_printk("Blocking external request\n");
> + dev_dbg(priv_dev->dev, "Blocking external request\n");

Instead, I would suggest adding a proper trace event here; one that
includes "priv_ep->flags" in the output.

-- 
balbi


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 6/6] usb: gadget: function: Add Generic USB Display support

2020-06-03 Thread Felipe Balbi


Hi,

Noralf Trønnes  writes:
>> I missed this completely until now.
>> Noralf Trønnes  writes:
>>> This adds the gadget side support for the Generic USB Display. It presents
>>> a DRM display device as a USB Display configured through configfs.
>>>
>>> The display is implemented as a vendor type USB interface with one bulk
>>> out endpoint. The protocol is implemented using control requests.
>>> lz4 compressed framebuffer data/pixels are sent over the bulk endpoint.
>>>
>>> The DRM part of the gadget is placed in the DRM subsystem since it reaches
>>> into the DRM internals.
>> 
>> First and foremost, could this be done in userspace using the raw gadget
>> or f_fs?
>> 
>
> An uncompressed 1920x1080-RGB565 frame is ~4MB. All frames can be
> compressed (lz4) even if just a little, so this is decompressed into the
> framebuffer of the attached DRM device. AFAIU I would need to be able to
> mmap the received bulk buffer if I were to do this from userspace
> without killing performance. So it doesn't look like I can use raw
> gadget or f_fs.

oh, yeah we couldn't map that much. I was thinking that maybe we could
transfer several small buffers instead of a single large one, but
perhaps that would complicate decompression?

>>> diff --git a/drivers/usb/gadget/function/f_gud_drm.c 
>>> b/drivers/usb/gadget/function/f_gud_drm.c
>>> new file mode 100644
>>> index ..9a2d6bb9739f
>>> --- /dev/null
>>> +++ b/drivers/usb/gadget/function/f_gud_drm.c
>>> @@ -0,0 +1,678 @@
>>> +struct f_gud_drm {
>>> +   struct usb_function func;
>>> +   struct work_struct worker;
>> 
>> why do you need a worker?
>> 
>
> The gadget runs in interrupt context and I need to call into the DRM
> subsystem which can sleep.

At some point someone wanted to provide a patch to run endpoint giveback
routine in process context, much like usb host stack does if
requested. That's currently not implemented, but should be doable by
modifying usb_gadget_giveback_request().

>>> +   size_t max_buffer_size;
>>> +   void *ctrl_req_buf;
>>> +
>>> +   u8 interface_id;
>>> +   struct usb_request *ctrl_req;
>>> +
>>> +   struct usb_ep *bulk_ep;
>>> +   struct usb_request *bulk_req;
>> 
>> single request? Don't you want to amortize the latency of
>> queue->complete by using a series of requests?
>> 
>
> I use only one request per update or partial update.
> I kmalloc the biggest buffer I can get (default 4MB) and tell the host
> about this size. If a frame doesn't fit, the host splits it up into
> partial updates. I already support partial updates so this is built in.
> Userspace can tell the graphics driver which portion of the framebuffer
> it has touched to avoid sending the full frame each time.
> Having one continous buffer simplifies decompression.

got it

> There's a control request preceding the bulk request which tells the
> area the update is for and whether it is compressed or not.
> I did some testing to see if I should avoid the control request overhead
> for split updates, but it turns out that the bottleneck is the
> decompression. The control request is just 400-500us, while the total
> time from control request to buffer is decompressed is 50-100ms
> (depending on how well the frame compresses).

yeah, that makes sense.

>>> +   struct gud_drm_gadget *gdg;
>>> +
>>> +   spinlock_t lock; /* Protects the following members: */
>>> +   bool ctrl_pending;
>>> +   bool status_pending;
>>> +   bool bulk_pending;
>>> +   bool disable_pending;
>> 
>> could this be a single u32 with #define'd flags? That would be atomic,
>> right?
>> 
>
> I have never grasped all the concurrency issues, but wouldn't I need
> memory barriers as well?

As far as I understand, {test_and_,}{set,clear,change}_bit() handle all
the required steps to guarantee proper atomic behavior. I haven't looked
at the implementation myself, though.

>>> +   u8 errno;
>> 
>> a global per-function error? Why?
>> 
>
> This is the result of the previously request operation. The host will
> request this value to see how it went. I might switch to using a bulk
> endpoint for status following a discussion with Alan Stern in the host
> driver thread in this patch series. If so I might not need this.

got it.

>>> +   u16 request;
>>> +   u16 value;
>> 
>> also why? Looks odd
>> 
>
> These values contains the operation (in addition to the payload) that
> the worker shall perform following the control-OUT requests.
>
> control-IN requests can run in interrupt context so in that case the
> payload is queued up immediately.

cool

>>> +static void f_gud_drm_bulk_complete(struct usb_ep *ep, struct usb_request 
>>> *req)
>>> +{
>>> +   struct f_gud_drm *fgd = req->context;
>>> +   unsigned long flags;
>>> +
>>> +   if (req->status || req->actual != req->length)
>>> +   return;
>> 
>> so, if we complete with an erroneous status or a short packet, you'll
>> ignore it?
>> 
>
> Hmm yeah. When I wrote this I thought that the bottleneck was the USB
> transfers, so I didn't want the host to

Re: [PATCH v3 6/6] usb: gadget: function: Add Generic USB Display support

2020-06-02 Thread Felipe Balbi


Hi,

I missed this completely until now.
Noralf Trønnes  writes:
> This adds the gadget side support for the Generic USB Display. It presents
> a DRM display device as a USB Display configured through configfs.
>
> The display is implemented as a vendor type USB interface with one bulk
> out endpoint. The protocol is implemented using control requests.
> lz4 compressed framebuffer data/pixels are sent over the bulk endpoint.
>
> The DRM part of the gadget is placed in the DRM subsystem since it reaches
> into the DRM internals.

First and foremost, could this be done in userspace using the raw gadget
or f_fs?

> diff --git a/drivers/usb/gadget/function/f_gud_drm.c 
> b/drivers/usb/gadget/function/f_gud_drm.c
> new file mode 100644
> index ..9a2d6bb9739f
> --- /dev/null
> +++ b/drivers/usb/gadget/function/f_gud_drm.c
> @@ -0,0 +1,678 @@
> +struct f_gud_drm {
> + struct usb_function func;
> + struct work_struct worker;

why do you need a worker?

> + size_t max_buffer_size;
> + void *ctrl_req_buf;
> +
> + u8 interface_id;
> + struct usb_request *ctrl_req;
> +
> + struct usb_ep *bulk_ep;
> + struct usb_request *bulk_req;

single request? Don't you want to amortize the latency of
queue->complete by using a series of requests?

> + struct gud_drm_gadget *gdg;
> +
> + spinlock_t lock; /* Protects the following members: */
> + bool ctrl_pending;
> + bool status_pending;
> + bool bulk_pending;
> + bool disable_pending;

could this be a single u32 with #define'd flags? That would be atomic,
right?

> + u8 errno;

a global per-function error? Why?

> + u16 request;
> + u16 value;

also why? Looks odd

> +};
> +
> +static inline struct f_gud_drm *func_to_f_gud_drm(struct usb_function *f)

let the compiler inline for you

> +{
> + return container_of(f, struct f_gud_drm, func);

could be a macro, but okay.

> +static inline struct f_gud_drm_opts *fi_to_f_gud_drm_opts(const struct 
> usb_function_instance *fi)

ditto

> +{
> + return container_of(fi, struct f_gud_drm_opts, func_inst);

ditto

> +}
> +
> +static inline struct f_gud_drm_opts *ci_to_f_gud_drm_opts(struct config_item 
> *item)

ditto

> +{
> + return container_of(to_config_group(item), struct f_gud_drm_opts,
> + func_inst.group);

ditto

> +}
> +
> +#define F_MUD_DEFINE_BULK_ENDPOINT_DESCRIPTOR(name, addr, size)  \
> + static struct usb_endpoint_descriptor name = {  \

const? Also, please check all the others

> +static void f_gud_drm_bulk_complete(struct usb_ep *ep, struct usb_request 
> *req)
> +{
> + struct f_gud_drm *fgd = req->context;
> + unsigned long flags;
> +
> + if (req->status || req->actual != req->length)
> + return;

so, if we complete with an erroneous status or a short packet, you'll
ignore it?

> + spin_lock_irqsave(&fgd->lock, flags);
> + fgd->bulk_pending = true;
> + spin_unlock_irqrestore(&fgd->lock, flags);
> +
> + queue_work(system_long_wq, &fgd->worker);

Do you need to offset this to a worker?

> +static int f_gud_drm_ctrl_req_set_buffer(struct f_gud_drm *fgd, void *buf, 
> size_t len)
> +{
> + int ret;
> +
> + if (len != sizeof(struct gud_drm_req_set_buffer))
> + return -EINVAL;
> +
> + ret = gud_drm_gadget_set_buffer(fgd->gdg, buf);
> + if (ret < 0)
> + return ret;
> +
> + if (ret > fgd->max_buffer_size)
> + return -EOVERFLOW;
> +
> + fgd->bulk_req->length = ret;
> +
> + return usb_ep_queue(fgd->bulk_ep, fgd->bulk_req, GFP_KERNEL);
> +}
> +
> +static void f_gud_drm_worker(struct work_struct *work)
> +{
> + struct f_gud_drm *fgd = container_of(work, struct f_gud_drm, worker);
> + bool ctrl_pending, bulk_pending, disable_pending;
> + struct gud_drm_gadget *gdg = fgd->gdg;
> + unsigned long flags;
> + u16 request, value;
> + int ret;
> +
> + spin_lock_irqsave(&fgd->lock, flags);
> + request = fgd->request;
> + value = fgd->value;
> + ctrl_pending = fgd->ctrl_pending;
> + bulk_pending = fgd->bulk_pending;
> + disable_pending = fgd->disable_pending;
> + spin_unlock_irqrestore(&fgd->lock, flags);
> +
> + pr_debug("%s: bulk_pending=%u ctrl_pending=%u disable_pending=%u\n",
> +  __func__, bulk_pending, ctrl_pending, disable_pending);

could we use dev_dbg() at least?

-- 
balbi


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [-next PATCH 0/4] sysfs and DEVICE_ATTR_

2017-12-21 Thread Felipe Balbi


Hi,

Joe Perches  writes:
>  drivers/usb/phy/phy-tahvo.c|  2 +-

Acked-by: Felipe Balbi 

-- 
balbi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/tilcdc: add missing clk_put in tilcdc_unload()

2014-11-19 Thread Felipe Balbi

On Wed, Nov 19, 2014 at 03:13:20PM +0100, Julien CHAUVEAU wrote:
> We need to call clk_put on display clock, in the same way as functional clock.
> 
> Signed-off-by: Julien CHAUVEAU 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 79a34cb..ccc1cdb 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -136,6 +136,9 @@ static int tilcdc_unload(struct drm_device *dev)
>   CPUFREQ_TRANSITION_NOTIFIER);
>  #endif
>  
> + if (priv->disp_clk)
> + clk_put(priv->disp_clk);
> +
>   if (priv->clk)
>   clk_put(priv->clk);

we should actually remove the priv->$clk check. clk_put() is safe
against NULL pointers.

-- 
balbi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:

[PATCH] regulator: stub out devm_regulator_get_exclusive

2014-10-24 Thread Felipe Balbi

Hi,

On Fri, Oct 24, 2014 at 09:11:38PM +0100, Mark Brown wrote:
> On Fri, Oct 24, 2014 at 02:15:11PM -0500, Felipe Balbi wrote:
> > If we don't stup that call out, we will have
> > build failures for any drivers using that function
> > when .config happens to have CONFIG_REGULATOR=n.
> > 
> > One such case below, found with randconfig
> > 
> > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ?mdp4_kms_init?:
> > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \
> 
> As previously and repeatedly reported the regulator usage in this driver
> appears extremely problematic, among these problems is that it almost
> certainly has no sensible reason to be using regulator_get_exclusive()
> or any variant of it.  Sadly every time it's been raised with the video
> people they've completely ignored the mail so here we are.
> 
> Right now not having the stub seems to only be affecting buggy users
> (which given the use cases for _exclusive() isn't *that* surprising) so
> I'm more inclined to leave this there in the hope that the users get
> fixed or we can at least get some sort of dialogue with the relevant
> maintainers.

quite frankly, flawed or not, I still think it's wrong of regulator
framework to cause a build break during randconfig. Pretty much every
other call is stubbed out, why wouldn't this be ? Moreover, if nobody
cared to this day, why would this randconfig build break change their
minds ?

Not that I really care, it's just yet another build break I need to
ignore when build-testing. Whatever.

-- 
balbi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/83d352f7/attachment-0001.sig>

[PATCH] regulator: stub out devm_regulator_get_exclusive

2014-10-24 Thread Felipe Balbi

On Fri, Oct 24, 2014 at 02:15:11PM -0500, Felipe Balbi wrote:
> If we don't stup that call out, we will have
> build failures for any drivers using that function
> when .config happens to have CONFIG_REGULATOR=n.
> 
> One such case below, found with randconfig
> 
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ?mdp4_kms_init?:
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \
>   of function ?devm_regulator_get_exclusive? 
> [-Werror=implicit-function-declaration]
>   mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd");
>   ^
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:16: error: assignment makes \
>   pointer from integer without a cast [-Werror]
>   mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd");
> ^
> Signed-off-by: Felipe Balbi 

randconfig attached.

-- 
balbi
-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.18.0-rc1 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_ARM_HAS_SG_CHAIN=y
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_VECTORS_BASE=0x
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_COMPILE_TEST=y
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_HANDLE_DOMAIN_IRQ=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_BUILD_BIN2C is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_GENERIC_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_MEMCG is not set
CONFIG_CGROUP_PERF=y
# CONFIG_CGROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_RELAY=y
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_SGETMASK_SYSCALL=y
# CONFIG_SYSFS_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
# CONFIG_FUTEX is not set
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
# CONFIG_PCI_QUIRKS is not set
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
# CONFIG_VM_EVENT_COUNTERS is not set
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_SYSTEM_TRUSTED_KEYRING is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
# CONFIG_OPROFILE is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_JUMP_LABEL=y
CONFIG_UPROBES=y
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_

[PATCH] regulator: stub out devm_regulator_get_exclusive

2014-10-24 Thread Felipe Balbi

If we don't stup that call out, we will have
build failures for any drivers using that function
when .config happens to have CONFIG_REGULATOR=n.

One such case below, found with randconfig

drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ?mdp4_kms_init?:
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \
of function ?devm_regulator_get_exclusive? 
[-Werror=implicit-function-declaration]
  mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd");
  ^
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:16: error: assignment makes \
pointer from integer without a cast [-Werror]
  mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd");
^
Signed-off-by: Felipe Balbi 
---
 include/linux/regulator/consumer.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/regulator/consumer.h 
b/include/linux/regulator/consumer.h
index d347c80..ff61f3b 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -291,6 +291,11 @@ regulator_get_optional(struct device *dev, const char *id)
return ERR_PTR(-ENODEV);
 }

+static inline struct regulator *__must_check
+devm_regulator_get_exclusive(struct device *dev, const char *id)
+{
+   return ERR_PTR(-ENODEV);
+}

 static inline struct regulator *__must_check
 devm_regulator_get_optional(struct device *dev, const char *id)
-- 
2.1.0.GIT

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

2014-09-25 Thread Felipe Balbi

On Thu, Sep 25, 2014 at 01:27:18PM +0530, Vinod Koul wrote:
> On Wed, Sep 24, 2014 at 03:32:19PM -0500, Felipe Balbi wrote:
> > > > > OK, I guess this is as good as it gets.
> > > > > 
> > > > > What tree would you like it go through?
> > > > 
> > > > Do we really need this new helper ? I mean, the very moment when we
> > > > decide to implement ->runtime_idle() we will need to get rid of this
> > > > change. I wonder if it's really valid...
> > > 
> > > I'm not sure I'm following?  This seems to simply implement what drivers
> > > have been doing already as one function.  Why would it be invalid to 
> > > reduce
> > > code duplication?
> > 
> > For two reasons:
> > 
> > 1) the helper has no inteligence whatsoever. It just calls the same
> > functions.
> > 
> > 2) the duplication will vanish whenever someone implements
> > ->runtime_idle() and have that call pm_runtime_autosuspend() (like PCI
> > and USB buses are doing today). This will just be yet another line that
> > needs to change.
> > 
> > Frankly though, no strong feelings, I just think it's a commit that
> > doesn't bring that any benefits other than looking like one line was
> > removed.
> and yes that is what it tries to do nothing more nothing less. If in future
> there are no users (today we have quite a few), then we can remove the dead
> macro, no harm. But that is not the situation today.

as I said, a commit that's bound to be useless. It's not like you're
saving 10 lines of code, it's only one. Replacing two simple lines with
a function which takes  almost as many characters to type .

IMO, this is pretty useless and I'd rather not see them in the drivers I
maintain, sorry.

cheers

-- 
balbi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/99ac80ca/attachment-0001.sig>

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

2014-09-24 Thread Felipe Balbi

On Wed, Sep 24, 2014 at 10:46:17PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, September 24, 2014 03:15:58 PM Felipe Balbi wrote:
> > On Wed, Sep 24, 2014 at 10:28:07PM +0200, Rafael J. Wysocki wrote:
> > > On Wednesday, September 24, 2014 09:44:50 PM Vinod Koul wrote:
> > > > This patch series adds a simple macro 
> > > > pm_runtime_last_busy_and_autosuspend()
> > > > which invokes pm_runtime_mark_last_busy() and 
> > > > pm_runtime_put_autosuspend()
> > > > sequentially. Then we do a tree wide update of current patterns which 
> > > > are
> > > > present. As evident from log below this pattern is frequent in the
> > > > kernel.
> > > > 
> > > > This series can be found at
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git
> > > > topic/pm_runtime_last_busy_and_autosuspend
> > > > 
> > > > Fengguang's kbuild has tested it so it shouldn't break things for 
> > > > anyone.
> > > > Barring one patch (explictyly mentioned in its changelog) rest are 
> > > > simple
> > > > replacements.
> > > > 
> > > > If all are okay, this should be merged thru PM tree as it depends on 
> > > > macro
> > > > addition.
> > > > 
> > > > Subhransu S. Prusty (1):
> > > >   PM: Add helper pm_runtime_last_busy_and_autosuspend()
> > > > 
> > > > Vinod Koul (26):
> > > >   dmaengine: ste_dma: use pm_runtime_last_busy_and_autosuspend helper
> > > >   extcon: arizona: use pm_runtime_last_busy_and_autosuspend helper
> > > >   drm/i915: use pm_runtime_last_busy_and_autosuspend helper
> > > >   drm/nouveau: use pm_runtime_last_busy_and_autosuspend helper
> > > >   drm/radeon: use pm_runtime_last_busy_and_autosuspend helper
> > > >   vga_switcheroo: use pm_runtime_last_busy_and_autosuspend helper
> > > >   i2c: designware: use pm_runtime_last_busy_and_autosuspend helper
> > > >   i2c: omap: use pm_runtime_last_busy_and_autosuspend helper
> > > >   i2c: qup: use pm_runtime_last_busy_and_autosuspend helper
> > > >   mfd: ab8500-gpadc: use pm_runtime_last_busy_and_autosuspend helper
> > > >   mfd: arizona: use pm_runtime_last_busy_and_autosuspend helper
> > > >   mei: use pm_runtime_last_busy_and_autosuspend helper
> > > >   mmc: use pm_runtime_last_busy_and_autosuspend helper
> > > >   mmc: mmci: use pm_runtime_last_busy_and_autosuspend helper
> > > >   mmc: omap_hsmmc: use pm_runtime_last_busy_and_autosuspend helper
> > > >   mmc: sdhci-pxav3: use pm_runtime_last_busy_and_autosuspend helper
> > > >   mmc: sdhci: use pm_runtime_last_busy_and_autosuspend helper
> > > >   NFC: trf7970a: use pm_runtime_last_busy_and_autosuspend helper
> > > >   pm2301-charger: use pm_runtime_last_busy_and_autosuspend helper
> > > >   spi: omap2-mcspi: use pm_runtime_last_busy_and_autosuspend helper
> > > >   spi: orion: use pm_runtime_last_busy_and_autosuspend helper
> > > >   spi: ti-qspi: use pm_runtime_last_busy_and_autosuspend helper
> > > >   spi: core: use pm_runtime_last_busy_and_autosuspend helper
> > > >   tty: serial: omap: use pm_runtime_last_busy_and_autosuspend helper
> > > >   usb: musb: omap2430: use pm_runtime_last_busy_and_autosuspend helper
> > > >   video: fbdev: use pm_runtime_last_busy_and_autosuspend helper
> > > > 
> > > >  Documentation/power/runtime_pm.txt  |4 ++
> > > >  drivers/dma/ste_dma40.c |   30 -
> > > >  drivers/extcon/extcon-arizona.c |6 +--
> > > >  drivers/gpu/drm/i915/intel_pm.c |3 +-
> > > >  drivers/gpu/drm/nouveau/nouveau_connector.c |3 +-
> > > >  drivers/gpu/drm/nouveau/nouveau_drm.c   |9 +---
> > > >  drivers/gpu/drm/radeon/radeon_connectors.c  |   15 ++
> > > >  drivers/gpu/drm/radeon/radeon_drv.c |5 +-
> > > >  drivers/gpu/drm/radeon/radeon_kms.c |6 +--
> > > >  drivers/gpu/vga/vga_switcheroo.c|7 +--
> > > >  drivers/i2c/busses/i2c-designware-core.c|3 +-
> > > >  drivers/i2c/busses/i2c-omap.c   |6 +--
> > > >  drivers/i2c/busses/i2c-qup.c|3 +-
> > > >  drivers/mfd/ab8500-gpadc.c  |6 +--
> > > >  drivers/mfd/arizona-irq.c

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

2014-09-24 Thread Felipe Balbi

On Wed, Sep 24, 2014 at 10:28:07PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, September 24, 2014 09:44:50 PM Vinod Koul wrote:
> > This patch series adds a simple macro pm_runtime_last_busy_and_autosuspend()
> > which invokes pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend()
> > sequentially. Then we do a tree wide update of current patterns which are
> > present. As evident from log below this pattern is frequent in the
> > kernel.
> > 
> > This series can be found at
> > git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git
> > topic/pm_runtime_last_busy_and_autosuspend
> > 
> > Fengguang's kbuild has tested it so it shouldn't break things for anyone.
> > Barring one patch (explictyly mentioned in its changelog) rest are simple
> > replacements.
> > 
> > If all are okay, this should be merged thru PM tree as it depends on macro
> > addition.
> > 
> > Subhransu S. Prusty (1):
> >   PM: Add helper pm_runtime_last_busy_and_autosuspend()
> > 
> > Vinod Koul (26):
> >   dmaengine: ste_dma: use pm_runtime_last_busy_and_autosuspend helper
> >   extcon: arizona: use pm_runtime_last_busy_and_autosuspend helper
> >   drm/i915: use pm_runtime_last_busy_and_autosuspend helper
> >   drm/nouveau: use pm_runtime_last_busy_and_autosuspend helper
> >   drm/radeon: use pm_runtime_last_busy_and_autosuspend helper
> >   vga_switcheroo: use pm_runtime_last_busy_and_autosuspend helper
> >   i2c: designware: use pm_runtime_last_busy_and_autosuspend helper
> >   i2c: omap: use pm_runtime_last_busy_and_autosuspend helper
> >   i2c: qup: use pm_runtime_last_busy_and_autosuspend helper
> >   mfd: ab8500-gpadc: use pm_runtime_last_busy_and_autosuspend helper
> >   mfd: arizona: use pm_runtime_last_busy_and_autosuspend helper
> >   mei: use pm_runtime_last_busy_and_autosuspend helper
> >   mmc: use pm_runtime_last_busy_and_autosuspend helper
> >   mmc: mmci: use pm_runtime_last_busy_and_autosuspend helper
> >   mmc: omap_hsmmc: use pm_runtime_last_busy_and_autosuspend helper
> >   mmc: sdhci-pxav3: use pm_runtime_last_busy_and_autosuspend helper
> >   mmc: sdhci: use pm_runtime_last_busy_and_autosuspend helper
> >   NFC: trf7970a: use pm_runtime_last_busy_and_autosuspend helper
> >   pm2301-charger: use pm_runtime_last_busy_and_autosuspend helper
> >   spi: omap2-mcspi: use pm_runtime_last_busy_and_autosuspend helper
> >   spi: orion: use pm_runtime_last_busy_and_autosuspend helper
> >   spi: ti-qspi: use pm_runtime_last_busy_and_autosuspend helper
> >   spi: core: use pm_runtime_last_busy_and_autosuspend helper
> >   tty: serial: omap: use pm_runtime_last_busy_and_autosuspend helper
> >   usb: musb: omap2430: use pm_runtime_last_busy_and_autosuspend helper
> >   video: fbdev: use pm_runtime_last_busy_and_autosuspend helper
> > 
> >  Documentation/power/runtime_pm.txt  |4 ++
> >  drivers/dma/ste_dma40.c |   30 -
> >  drivers/extcon/extcon-arizona.c |6 +--
> >  drivers/gpu/drm/i915/intel_pm.c |3 +-
> >  drivers/gpu/drm/nouveau/nouveau_connector.c |3 +-
> >  drivers/gpu/drm/nouveau/nouveau_drm.c   |9 +---
> >  drivers/gpu/drm/radeon/radeon_connectors.c  |   15 ++
> >  drivers/gpu/drm/radeon/radeon_drv.c |5 +-
> >  drivers/gpu/drm/radeon/radeon_kms.c |6 +--
> >  drivers/gpu/vga/vga_switcheroo.c|7 +--
> >  drivers/i2c/busses/i2c-designware-core.c|3 +-
> >  drivers/i2c/busses/i2c-omap.c   |6 +--
> >  drivers/i2c/busses/i2c-qup.c|3 +-
> >  drivers/mfd/ab8500-gpadc.c  |6 +--
> >  drivers/mfd/arizona-irq.c   |3 +-
> >  drivers/misc/mei/client.c   |   12 ++
> >  drivers/mmc/core/core.c |3 +-
> >  drivers/mmc/host/mmci.c |   12 ++
> >  drivers/mmc/host/omap_hsmmc.c   |   19 ++---
> >  drivers/mmc/host/sdhci-pxav3.c  |6 +--
> >  drivers/mmc/host/sdhci.c|3 +-
> >  drivers/nfc/trf7970a.c  |3 +-
> >  drivers/power/pm2301_charger.c  |3 +-
> >  drivers/spi/spi-omap2-mcspi.c   |9 +---
> >  drivers/spi/spi-orion.c |3 +-
> >  drivers/spi/spi-ti-qspi.c   |5 +-
> >  drivers/spi/spi.c   |6 +--
> >  drivers/tty/serial/omap-serial.c|   60 
> > +--
> >  drivers/usb/musb/omap2430.c |6 +--
> >  drivers/video/fbdev/auo_k190x.c |9 +---
> >  include/linux/pm_runtime.h  |6 +++
> >  31 files changed, 97 insertions(+), 177 deletions(-)
> 
> OK, I guess this is as good as it gets.
> 
> What tree would you like it go through?

Do we really need this new helper ? I mean, the very moment when we
decide to implement ->runtime_idle() we will need to get rid of this
change. I wonder if it's real

possible deadlock on nouveau

2014-05-06 Thread Felipe Balbi

Hi,

Just caught this with v3.14-rc4 running with

01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce 
GTX 650] (rev a1)

full dmesg attached

[  239.589213] ==
[  239.589214] [ INFO: possible circular locking dependency detected ]
[  239.589216] 3.15.0-rc4-fb+ #5 Not tainted
[  239.589217] ---
[  239.589218] swapper/1/0 is trying to acquire lock:
[  239.589219]  (&(&priv->lock)->rlock#2){-.}, at: [] 
nouveau_therm_update+0x48/0x310
[  239.589228] 
[  239.589228] but task is already holding lock:
[  239.589230]  (&(&priv->sensor.alarm_program_lock)->rlock){-.}, at: 
[] alarm_timer_callback+0x54/0xe0
[  239.589234] 
[  239.589234] which lock already depends on the new lock.
[  239.589234] 
[  239.589236] 
[  239.589236] the existing dependency chain (in reverse order) is:
[  239.589237] 
[  239.589237] -> #1 (&(&priv->sensor.alarm_program_lock)->rlock){-.}:
[  239.589240][] lock_acquire+0xb5/0x160
[  239.589243][] _raw_spin_lock_irqsave+0x56/0x90
[  239.589247][] alarm_timer_callback+0x54/0xe0
[  239.589249][] nv04_timer_alarm_trigger+0x12e/0x170
[  239.589252][] nv04_timer_alarm+0x7e/0xe0
[  239.589255][] nouveau_therm_update+0x26d/0x310
[  239.589257][] nouveau_therm_alarm+0x1a/0x20
[  239.589259][] nv04_timer_alarm_trigger+0x12e/0x170
[  239.589261][] nv04_timer_intr+0x6b/0x90
[  239.589263][] nouveau_mc_intr+0x141/0x1a0
[  239.589265][] handle_irq_event_percpu+0x47/0x1d0
[  239.589268][] handle_irq_event+0x3d/0x60
[  239.589270][] handle_edge_irq+0x77/0x130
[  239.589272][] handle_irq+0xbf/0x150
[  239.589275][] do_IRQ+0x4f/0xf0
[  239.589277][] ret_from_intr+0x0/0x1a
[  239.589279][] cpuidle_enter+0x17/0x20
[  239.589283][] cpu_startup_entry+0x242/0x470
[  239.589287][] rest_init+0xc6/0xd0
[  239.589290][] start_kernel+0x386/0x391
[  239.589293][] x86_64_start_reservations+0x2a/0x2c
[  239.589296][] x86_64_start_kernel+0x13e/0x14d
[  239.589297] 
[  239.589297] -> #0 (&(&priv->lock)->rlock#2){-.}:
[  239.589300][] __lock_acquire+0x1565/0x1c30
[  239.589302][] lock_acquire+0xb5/0x160
[  239.589304][] _raw_spin_lock_irqsave+0x56/0x90
[  239.589306][] nouveau_therm_update+0x48/0x310
[  239.589308][] nouveau_therm_alarm+0x1a/0x20
[  239.589310][] nv04_timer_alarm_trigger+0x12e/0x170
[  239.589312][] nv04_timer_alarm+0x7e/0xe0
[  239.589315][] alarm_timer_callback+0xdd/0xe0
[  239.589317][] nv04_timer_alarm_trigger+0x12e/0x170
[  239.589319][] nv04_timer_intr+0x6b/0x90
[  239.589321][] nouveau_mc_intr+0x141/0x1a0
[  239.589323][] handle_irq_event_percpu+0x47/0x1d0
[  239.589325][] handle_irq_event+0x3d/0x60
[  239.589327][] handle_edge_irq+0x77/0x130
[  239.589329][] handle_irq+0xbf/0x150
[  239.589330][] do_IRQ+0x4f/0xf0
[  239.589332][] ret_from_intr+0x0/0x1a
[  239.589334][] cpuidle_enter+0x17/0x20
[  239.589336][] cpu_startup_entry+0x242/0x470
[  239.589338][] start_secondary+0x1a8/0x210
[  239.589343] 
[  239.589343] other info that might help us debug this:
[  239.589343] 
[  239.589344]  Possible unsafe locking scenario:
[  239.589344] 
[  239.589345]CPU0CPU1
[  239.589346]
[  239.589347]   lock(&(&priv->sensor.alarm_program_lock)->rlock);
[  239.589349]lock(&(&priv->lock)->rlock#2);
[  239.589351]
lock(&(&priv->sensor.alarm_program_lock)->rlock);
[  239.589353]   lock(&(&priv->lock)->rlock#2);
[  239.589355] 
[  239.589355]  *** DEADLOCK ***
[  239.589355] 
[  239.589357] 1 lock held by swapper/1/0:
[  239.589358]  #0:  (&(&priv->sensor.alarm_program_lock)->rlock){-.}, at: 
[] alarm_timer_callback+0x54/0xe0
[  239.589362] 
[  239.589362] stack backtrace:
[  239.589364] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.15.0-rc4-fb+ #5
[  239.589366] Hardware name: LENOVO 10120/ , BIOS I1KT15AUS 03/28/2013
[  239.589367]  826667d0 880330803b30 818a1afc 
826667d0
[  239.589370]  880330803b70 8189caa9 880330803bc0 
88032e70c778
[  239.589372]  0001 0001 88032e70bf30 
88032e70c778
[  239.589375] Call Trace:
[  239.589376][] dump_stack+0x4d/0x66
[  239.589382]  [] print_circular_bug+0x200/0x20e
[  239.589384]  [] __lock_acquire+0x1565/0x1c30
[  239.589386]  [] ? __lock_acquire+0x3b3/0x1c30
[  239.589388]  [] lock_acquire+0xb5/0x160
[  239.589391]  [] ? nouveau_therm_update+0x48/0x310
[  239.589393]  [] _raw_spin_lock_irqsave+0x56/0x90
[  239.589395]  [] ? nouveau_therm_update+0x48/0x310
[  239.589398]  [] nouveau_therm_update+

[PATCH] drm/tilcdc increase allowable supported resolution

2014-04-24 Thread Felipe Balbi

On Mon, Mar 03, 2014 at 01:08:58PM -0600, Felipe Balbi wrote:
> From: Darren Etheridge 
> 
> 1680x1050 appears to also be within the bandwidth capabilities
> of the device and memory infrastructure.
> 
> Signed-off-by: Darren Etheridge 

ping

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> index 5bb64e3..b47ec24 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> @@ -43,7 +43,7 @@
>   * with optimized DDR & EMIF settings tweaked 1920x1080 at 24 appears to
>   * be supportable
>   */
> -#define TILCDC_DEFAULT_MAX_BANDWIDTH  (1280*1024*60)
> +#define TILCDC_DEFAULT_MAX_BANDWIDTH  (1680*1050*60)
>  
>  
>  struct tilcdc_drm_private {
> -- 
> 1.9.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
balbi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140424/813536ba/attachment-0001.sig>

[PATCH] drm/tilcdc: restore correct display mode and contents on pm resume

2014-04-24 Thread Felipe Balbi

On Mon, Mar 03, 2014 at 01:08:56PM -0600, Felipe Balbi wrote:
> From: Darren Etheridge 
> 
> On resume the screen contents were not being restored properly.  Looking at
> other DRM drivers it seems a call to drm_helper_resume_force_mode() is needed
> in the resume handler to force restoration of the mode and framebuffer data.
> 
> Signed-off-by: Darren Etheridge 

ping

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 171a820..1a5ddfa 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -563,6 +563,13 @@ static int tilcdc_pm_resume(struct device *dev)
>   if (registers[i].save && (priv->rev >= registers[i].rev))
>   tilcdc_write(ddev, registers[i].reg, 
> priv->saved_register[n++]);
>  
> + /*
> +  * if this call isn't here, the display is blank on return from
> +  * suspend.  With this call here the contents of the framebuffer
> +  * during suspend are restored correctly.
> +  */
> + drm_helper_resume_force_mode(ddev);
> +
>   drm_kms_helper_poll_enable(ddev);
>  
>   return 0;
> -- 
> 1.9.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
balbi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140424/ead015f8/attachment.sig>

[PATCH] drm/tilcdc increase allowable supported resolution

2014-03-03 Thread Felipe Balbi

From: Darren Etheridge 

1680x1050 appears to also be within the bandwidth capabilities
of the device and memory infrastructure.

Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 5bb64e3..b47ec24 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -43,7 +43,7 @@
  * with optimized DDR & EMIF settings tweaked 1920x1080 at 24 appears to
  * be supportable
  */
-#define TILCDC_DEFAULT_MAX_BANDWIDTH  (1280*1024*60)
+#define TILCDC_DEFAULT_MAX_BANDWIDTH  (1680*1050*60)


 struct tilcdc_drm_private {
-- 
1.9.0

[PATCH] drm/tilcdc: restore correct display mode and contents on pm resume

2014-03-03 Thread Felipe Balbi

From: Darren Etheridge 

On resume the screen contents were not being restored properly.  Looking at
other DRM drivers it seems a call to drm_helper_resume_force_mode() is needed
in the resume handler to force restoration of the mode and framebuffer data.

Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 171a820..1a5ddfa 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -563,6 +563,13 @@ static int tilcdc_pm_resume(struct device *dev)
if (registers[i].save && (priv->rev >= registers[i].rev))
tilcdc_write(ddev, registers[i].reg, 
priv->saved_register[n++]);

+   /*
+* if this call isn't here, the display is blank on return from
+* suspend.  With this call here the contents of the framebuffer
+* during suspend are restored correctly.
+*/
+   drm_helper_resume_force_mode(ddev);
+
drm_kms_helper_poll_enable(ddev);

return 0;
-- 
1.9.0

Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks

2013-09-23 Thread Felipe Balbi

Hi,

On Fri, Sep 20, 2013 at 02:49:38PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> > Hi,
> > 
> > On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > > Use platform_device_register_full() for those drivers which can, to
> > > avoid messing directly with DMA masks.  This can only be done when
> > > the driver does not need to access the allocated musb platform device
> > > from within its callbacks, which may be called during the musb
> > > device probing.
> > > 
> > > Signed-off-by: Russell King 
> > 
> > you want me to carry this one through my tree or you prefer getting my
> > Acked-by ? Either way works for me:
> > 
> > Acked-by: Felipe Balbi 
> > 
> > there's also the third option of me setting up a branch with only this
> > patch and we both merge it, that'd also work.
> 
> I think this patch is sufficiently stand-alone that it should be fine
> if you want to take it through your tree.  That may be better in the
> long run to avoid conflicts with this patch and any future work in
> this area during this cycle.

awesome, i'll take this one early next week.

-- 
balbi


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks

2013-09-23 Thread Felipe Balbi

Hi,

On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> Use platform_device_register_full() for those drivers which can, to
> avoid messing directly with DMA masks.  This can only be done when
> the driver does not need to access the allocated musb platform device
> from within its callbacks, which may be called during the musb
> device probing.
> 
> Signed-off-by: Russell King 

you want me to carry this one through my tree or you prefer getting my
Acked-by ? Either way works for me:

Acked-by: Felipe Balbi 

there's also the third option of me setting up a branch with only this
patch and we both merge it, that'd also work.

cheers

-- 
balbi


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 37/51] DMA-API: usb: use new dma_coerce_mask_and_coherent()

2013-09-23 Thread Felipe Balbi

Hi,

On Thu, Sep 19, 2013 at 11:02:03PM +0100, Russell King wrote:
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index c10b324..8b20c70 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -119,9 +119,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
>* Since shared usb code relies on it, set it here for now.
>* Once we move to full device tree support this will vanish off.
>*/
> - if (!dev->dma_mask)
> - dev->dma_mask = &dev->coherent_dma_mask;
> - ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
>   if (ret)
>   goto err1;
>  
> diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
> index d0759c5..6fa82d6 100644
> --- a/drivers/usb/host/ehci-omap.c
> +++ b/drivers/usb/host/ehci-omap.c
> @@ -144,9 +144,7 @@ static int ehci_hcd_omap_probe(struct platform_device 
> *pdev)
>* Since shared usb code relies on it, set it here for now.
>* Once we have dma capability bindings this can go away.
>*/
> - if (!dev->dma_mask)
> - dev->dma_mask = &dev->coherent_dma_mask;
> - ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
>   if (ret)
>   return ret;

for dwc3 and ehci-omap:

Acked-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()

2013-09-23 Thread Felipe Balbi

Hi,

On Thu, Sep 19, 2013 at 11:01:03PM +0100, Russell King wrote:
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index 2f2e88a..c10b324 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -121,8 +121,9 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
>*/
>   if (!dev->dma_mask)
>   dev->dma_mask = &dev->coherent_dma_mask;
> - if (!dev->coherent_dma_mask)
> - dev->coherent_dma_mask = DMA_BIT_MASK(32);
> + ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> + if (ret)
> + goto err1;
>  
>   platform_set_drvdata(pdev, exynos);
>  
> diff --git a/drivers/usb/gadget/lpc32xx_udc.c 
> b/drivers/usb/gadget/lpc32xx_udc.c
> index 67128be..6a2a65a 100644
> --- a/drivers/usb/gadget/lpc32xx_udc.c
> +++ b/drivers/usb/gadget/lpc32xx_udc.c
> @@ -3078,7 +3078,9 @@ static int __init lpc32xx_udc_probe(struct 
> platform_device *pdev)
>udc->isp1301_i2c_client->addr);
>  
>   pdev->dev.dma_mask = &lpc32xx_usbd_dmamask;
> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + retval = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + if (retval)
> +     goto resource_fail;
>  
>   udc->board = &lpc32xx_usbddata;
>  

for dwc3 and drivers/usb/gadget:

Acked-by: Felipe Balbi 

pretty cool work :-)

-- 
balbi


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915 not working on Dell e6410

2013-02-25 Thread Felipe Balbi

Hi,

On Mon, Feb 25, 2013 at 02:49:07PM +, Chris Wilson wrote:
> On Mon, Feb 25, 2013 at 04:43:12PM +0200, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Feb 25, 2013 at 02:39:18PM +, Chris Wilson wrote:
> > > On Mon, Feb 25, 2013 at 04:24:11PM +0200, Felipe Balbi wrote:
> > > > Hi folks,
> > > > 
> > > > I have a Dell e6410 whose framebuffer gets corrupted with v3.7.9 and
> > > > v3.8.0 but works fine with v3.6.11.
> > > > 
> > > > Below you can find lspci and my .config, maybe I'm missing something ?
> 
> That looks like https://bugzilla.freedesktop.org/show_bug.cgi?id=60391
> which is fixed by
> 
> commit da88a5f7f7d434e2cde1b3e19d952e6d84533662
> Author: Chris Wilson 
> Date:   Wed Feb 13 09:31:53 2013 +
> 
> drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK
> 
> or by passing intel_iommu=off on the commandline.

and so it does, thanks. That's going to be merged on v3.9 right ? Hope
there's a stable tag in it, thanks

cheers

-- 
balbi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130225/475cebf4/attachment.pgp>

i915 not working on Dell e6410

2013-02-25 Thread Felipe Balbi

Hi,

On Mon, Feb 25, 2013 at 02:39:18PM +, Chris Wilson wrote:
> On Mon, Feb 25, 2013 at 04:24:11PM +0200, Felipe Balbi wrote:
> > Hi folks,
> > 
> > I have a Dell e6410 whose framebuffer gets corrupted with v3.7.9 and
> > v3.8.0 but works fine with v3.6.11.
> > 
> > Below you can find lspci and my .config, maybe I'm missing something ?
> 
> You don't describe how the fb gets corrupted, so it is impossible to
> guess the likely cause. When in doubt, please attach a photograph of
> the corruption.

attached.

-- 
balbi
-- next part --
A non-text attachment was scrubbed...
Name: IMG_20130225_161358.jpg
Type: image/jpeg
Size: 3992755 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130225/591ba647/attachment-0001.jpg>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130225/591ba647/attachment-0001.pgp>

i915 not working on Dell e6410

2013-02-25 Thread Felipe Balbi

Hi folks,

I have a Dell e6410 whose framebuffer gets corrupted with v3.7.9 and
v3.8.0 but works fine with v3.6.11.

Below you can find lspci and my .config, maybe I'm missing something ?

8<-

00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
Subsystem: Dell Device 040a
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated 
Graphics Controller (rev 02) (prog-if 00 [VGA controller])
Subsystem: Dell Device 040a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Address:   Data: 
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-

00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network 
Connection (rev 05)
Subsystem: Dell Latitude E6410
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, 
L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ 
TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency 
L0 <1us, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ 
DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ 
Surprise+
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- 
LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- 
Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- 
Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- 
CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID , PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF 
Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, 
OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, 
EqualizationComplete-, EqualizationPhase1-
 EqualizationPhase2-, EqualizationPhase3-, 
LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address:   Data: 
Capabilities: [90] Subsystem: Dell Device 040a
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport

00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 2 (rev 05) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
Dev

Re: i915 not working on Dell e6410

2013-02-25 Thread Felipe Balbi

Hi,

On Mon, Feb 25, 2013 at 02:49:07PM +, Chris Wilson wrote:
> On Mon, Feb 25, 2013 at 04:43:12PM +0200, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Feb 25, 2013 at 02:39:18PM +, Chris Wilson wrote:
> > > On Mon, Feb 25, 2013 at 04:24:11PM +0200, Felipe Balbi wrote:
> > > > Hi folks,
> > > > 
> > > > I have a Dell e6410 whose framebuffer gets corrupted with v3.7.9 and
> > > > v3.8.0 but works fine with v3.6.11.
> > > > 
> > > > Below you can find lspci and my .config, maybe I'm missing something ?
> 
> That looks like https://bugzilla.freedesktop.org/show_bug.cgi?id=60391
> which is fixed by
> 
> commit da88a5f7f7d434e2cde1b3e19d952e6d84533662
> Author: Chris Wilson 
> Date:   Wed Feb 13 09:31:53 2013 +
> 
> drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK
> 
> or by passing intel_iommu=off on the commandline.

and so it does, thanks. That's going to be merged on v3.9 right ? Hope
there's a stable tag in it, thanks

cheers

-- 
balbi


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: fixup headers_check

2011-01-17 Thread Felipe Balbi

Hi,

On Sun, Jan 16, 2011 at 09:42:37PM +1000, Dave Airlie wrote:
> I'll push the attached I think this time.

the point of headers_check is exactly to prevent indirect inclusion.
This is even 1st topic o SubmitChecklist:

" 1: If you use a facility then #include the file that defines/declares
that facility.  Don't depend on other header files pulling in that you use."

-- 
balbi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: fixup headers_check

2011-01-17 Thread Felipe Balbi

On Sun, Jan 16, 2011 at 01:16:16PM +0200, Felipe Balbi wrote:
> I truly have those types in use.

I meant you :-p

-- 
balbi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: fixup headers_check

2011-01-17 Thread Felipe Balbi

On Sun, Jan 16, 2011 at 11:07:32AM +, Chris Wilson wrote:
> On Sun, 16 Jan 2011 12:46:22 +0200, Felipe Balbi  wrote:
> > Drop the following headers_check errors:
> > /linux-2.6/usr/include/drm/drm_mode.h:85: found
> > __[us]{8,16,32,64} type without #include 
> > /linux-2.6/usr/include/drm/i915_drm.h:120: found
> > __[us]{8,16,32,64} type without #include 
> > /linux-2.6/usr/include/drm/mga_drm.h:260: found
> > __[us]{8,16,32,64} type without #include 
> > /linux-2.6/usr/include/drm/radeon_drm.h:758: found
> > __[us]{8,16,32,64} type without #include 
> > /linux-2.6/usr/include/drm/via_drm.h:117: found
> > __[us]{8,16,32,64} type without #include 
> > 
> > Cc: David Airlie 
> > Cc: Chris Wilson 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-ker...@vger.kernel.org
> > Signed-off-by: Felipe Balbi 
> > ---
> >  include/drm/drm_mode.h   |2 ++
> >  include/drm/i915_drm.h   |1 +
> >  include/drm/mga_drm.h|1 +
> >  include/drm/radeon_drm.h |1 +
> >  include/drm/via_drm.h|1 +
> >  5 files changed, 6 insertions(+), 0 deletions(-)
> > 
> > diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> > index 0fc7397..1678d7b 100644
> > --- a/include/drm/drm_mode.h
> > +++ b/include/drm/drm_mode.h
> > @@ -27,6 +27,8 @@
> >  #ifndef _DRM_MODE_H
> >  #define _DRM_MODE_H
> >  
> > +#include 
> > +
> 
> Would
> 
> #if 0
> #include  /* silence make header_check */
> #endif
> 
> be an acceptable compromise?

Why would you want to do that ? I truly have those types in use.
headers_check seems to be reporting correctly.

-- 
balbi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: fixup headers_check

2011-01-17 Thread Felipe Balbi

Hi,

On Sun, Jan 16, 2011 at 12:46:22PM +0200, Felipe Balbi wrote:
> Drop the following headers_check errors:
> /linux-2.6/usr/include/drm/drm_mode.h:85: found
> __[us]{8,16,32,64} type without #include 
> /linux-2.6/usr/include/drm/i915_drm.h:120: found
> __[us]{8,16,32,64} type without #include 
> /linux-2.6/usr/include/drm/mga_drm.h:260: found
> __[us]{8,16,32,64} type without #include 
> /linux-2.6/usr/include/drm/radeon_drm.h:758: found
> __[us]{8,16,32,64} type without #include 
> /linux-2.6/usr/include/drm/via_drm.h:117: found
> __[us]{8,16,32,64} type without #include 
> 
> Cc: David Airlie 
> Cc: Chris Wilson 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Felipe Balbi 

$SUBJECT shouldn't have number actually. Git added those automatically.
Oh well, not a big deal.

-- 
balbi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm: fixup headers_check

2011-01-17 Thread Felipe Balbi

Drop the following headers_check errors:
/linux-2.6/usr/include/drm/drm_mode.h:85: found
__[us]{8,16,32,64} type without #include 
/linux-2.6/usr/include/drm/i915_drm.h:120: found
__[us]{8,16,32,64} type without #include 
/linux-2.6/usr/include/drm/mga_drm.h:260: found
__[us]{8,16,32,64} type without #include 
/linux-2.6/usr/include/drm/radeon_drm.h:758: found
__[us]{8,16,32,64} type without #include 
/linux-2.6/usr/include/drm/via_drm.h:117: found
__[us]{8,16,32,64} type without #include 

Cc: David Airlie 
Cc: Chris Wilson 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Felipe Balbi 
---
 include/drm/drm_mode.h   |2 ++
 include/drm/i915_drm.h   |1 +
 include/drm/mga_drm.h|1 +
 include/drm/radeon_drm.h |1 +
 include/drm/via_drm.h|1 +
 5 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 0fc7397..1678d7b 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -27,6 +27,8 @@
 #ifndef _DRM_MODE_H
 #define _DRM_MODE_H
 
+#include 
+
 #define DRM_DISPLAY_INFO_LEN   32
 #define DRM_CONNECTOR_NAME_LEN 32
 #define DRM_DISPLAY_MODE_LEN   32
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 0039f1f..4b211c8 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -27,6 +27,7 @@
 #ifndef _I915_DRM_H_
 #define _I915_DRM_H_
 
+#include 
 #include "drm.h"
 
 /* Please note that modifications to all structs defined here are
diff --git a/include/drm/mga_drm.h b/include/drm/mga_drm.h
index c16097f..1107097 100644
--- a/include/drm/mga_drm.h
+++ b/include/drm/mga_drm.h
@@ -35,6 +35,7 @@
 #ifndef __MGA_DRM_H__
 #define __MGA_DRM_H__
 
+#include 
 #include "drm.h"
 
 /* WARNING: If you change any of these defines, make sure to change the
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index e95a86b..f9ec151 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -33,6 +33,7 @@
 #ifndef __RADEON_DRM_H__
 #define __RADEON_DRM_H__
 
+#include 
 #include "drm.h"
 
 /* WARNING: If you change any of these defines, make sure to change the
diff --git a/include/drm/via_drm.h b/include/drm/via_drm.h
index fd11a5b..23880b0 100644
--- a/include/drm/via_drm.h
+++ b/include/drm/via_drm.h
@@ -24,6 +24,7 @@
 #ifndef _VIA_DRM_H_
 #define _VIA_DRM_H_
 
+#include 
 #include "drm.h"
 
 /* WARNING: These defines must be the same as what the Xserver uses.
-- 
1.7.3.4.598.g85356

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm: fixup headers_check

2011-01-16 Thread Felipe Balbi

Hi,

On Sun, Jan 16, 2011 at 09:42:37PM +1000, Dave Airlie wrote:
> I'll push the attached I think this time.

the point of headers_check is exactly to prevent indirect inclusion.
This is even 1st topic o SubmitChecklist:

" 1: If you use a facility then #include the file that defines/declares
that facility.  Don't depend on other header files pulling in that you use."

-- 
balbi

[PATCH 1/2] drm: fixup headers_check

2011-01-16 Thread Felipe Balbi

On Sun, Jan 16, 2011 at 01:16:16PM +0200, Felipe Balbi wrote:
> I truly have those types in use.

I meant you :-p

-- 
balbi

[PATCH 1/2] drm: fixup headers_check

2011-01-16 Thread Felipe Balbi

On Sun, Jan 16, 2011 at 11:07:32AM +, Chris Wilson wrote:
> On Sun, 16 Jan 2011 12:46:22 +0200, Felipe Balbi  wrote:
> > Drop the following headers_check errors:
> > /linux-2.6/usr/include/drm/drm_mode.h:85: found
> > __[us]{8,16,32,64} type without #include 
> > /linux-2.6/usr/include/drm/i915_drm.h:120: found
> > __[us]{8,16,32,64} type without #include 
> > /linux-2.6/usr/include/drm/mga_drm.h:260: found
> > __[us]{8,16,32,64} type without #include 
> > /linux-2.6/usr/include/drm/radeon_drm.h:758: found
> > __[us]{8,16,32,64} type without #include 
> > /linux-2.6/usr/include/drm/via_drm.h:117: found
> > __[us]{8,16,32,64} type without #include 
> > 
> > Cc: David Airlie 
> > Cc: Chris Wilson 
> > Cc: dri-devel at lists.freedesktop.org
> > Cc: linux-kernel at vger.kernel.org
> > Signed-off-by: Felipe Balbi 
> > ---
> >  include/drm/drm_mode.h   |2 ++
> >  include/drm/i915_drm.h   |1 +
> >  include/drm/mga_drm.h|1 +
> >  include/drm/radeon_drm.h |1 +
> >  include/drm/via_drm.h|1 +
> >  5 files changed, 6 insertions(+), 0 deletions(-)
> > 
> > diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> > index 0fc7397..1678d7b 100644
> > --- a/include/drm/drm_mode.h
> > +++ b/include/drm/drm_mode.h
> > @@ -27,6 +27,8 @@
> >  #ifndef _DRM_MODE_H
> >  #define _DRM_MODE_H
> >  
> > +#include 
> > +
> 
> Would
> 
> #if 0
> #include  /* silence make header_check */
> #endif
> 
> be an acceptable compromise?

Why would you want to do that ? I truly have those types in use.
headers_check seems to be reporting correctly.

-- 
balbi

[PATCH 1/2] drm: fixup headers_check

2011-01-16 Thread Felipe Balbi

Hi,

On Sun, Jan 16, 2011 at 12:46:22PM +0200, Felipe Balbi wrote:
> Drop the following headers_check errors:
> /linux-2.6/usr/include/drm/drm_mode.h:85: found
> __[us]{8,16,32,64} type without #include 
> /linux-2.6/usr/include/drm/i915_drm.h:120: found
> __[us]{8,16,32,64} type without #include 
> /linux-2.6/usr/include/drm/mga_drm.h:260: found
> __[us]{8,16,32,64} type without #include 
> /linux-2.6/usr/include/drm/radeon_drm.h:758: found
> __[us]{8,16,32,64} type without #include 
> /linux-2.6/usr/include/drm/via_drm.h:117: found
> __[us]{8,16,32,64} type without #include 
> 
> Cc: David Airlie 
> Cc: Chris Wilson 
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Felipe Balbi 

$SUBJECT shouldn't have number actually. Git added those automatically.
Oh well, not a big deal.

-- 
balbi

[PATCH 1/2] drm: fixup headers_check

2011-01-16 Thread Felipe Balbi

Drop the following headers_check errors:
/linux-2.6/usr/include/drm/drm_mode.h:85: found
__[us]{8,16,32,64} type without #include 
/linux-2.6/usr/include/drm/i915_drm.h:120: found
__[us]{8,16,32,64} type without #include 
/linux-2.6/usr/include/drm/mga_drm.h:260: found
__[us]{8,16,32,64} type without #include 
/linux-2.6/usr/include/drm/radeon_drm.h:758: found
__[us]{8,16,32,64} type without #include 
/linux-2.6/usr/include/drm/via_drm.h:117: found
__[us]{8,16,32,64} type without #include 

Cc: David Airlie 
Cc: Chris Wilson 
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Felipe Balbi 
---
 include/drm/drm_mode.h   |2 ++
 include/drm/i915_drm.h   |1 +
 include/drm/mga_drm.h|1 +
 include/drm/radeon_drm.h |1 +
 include/drm/via_drm.h|1 +
 5 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 0fc7397..1678d7b 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -27,6 +27,8 @@
 #ifndef _DRM_MODE_H
 #define _DRM_MODE_H

+#include 
+
 #define DRM_DISPLAY_INFO_LEN   32
 #define DRM_CONNECTOR_NAME_LEN 32
 #define DRM_DISPLAY_MODE_LEN   32
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 0039f1f..4b211c8 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -27,6 +27,7 @@
 #ifndef _I915_DRM_H_
 #define _I915_DRM_H_

+#include 
 #include "drm.h"

 /* Please note that modifications to all structs defined here are
diff --git a/include/drm/mga_drm.h b/include/drm/mga_drm.h
index c16097f..1107097 100644
--- a/include/drm/mga_drm.h
+++ b/include/drm/mga_drm.h
@@ -35,6 +35,7 @@
 #ifndef __MGA_DRM_H__
 #define __MGA_DRM_H__

+#include 
 #include "drm.h"

 /* WARNING: If you change any of these defines, make sure to change the
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index e95a86b..f9ec151 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -33,6 +33,7 @@
 #ifndef __RADEON_DRM_H__
 #define __RADEON_DRM_H__

+#include 
 #include "drm.h"

 /* WARNING: If you change any of these defines, make sure to change the
diff --git a/include/drm/via_drm.h b/include/drm/via_drm.h
index fd11a5b..23880b0 100644
--- a/include/drm/via_drm.h
+++ b/include/drm/via_drm.h
@@ -24,6 +24,7 @@
 #ifndef _VIA_DRM_H_
 #define _VIA_DRM_H_

+#include 
 #include "drm.h"

 /* WARNING: These defines must be the same as what the Xserver uses.
-- 
1.7.3.4.598.g85356

Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

Re: [PATCH 1/4] usb: cdns3: gadget: Replace trace_printk by dev_dbg

Re: [PATCH 1/4] usb: cdns3: gadget: Replace trace_printk by dev_dbg

Re: [PATCH v3 6/6] usb: gadget: function: Add Generic USB Display support

Re: [PATCH v3 6/6] usb: gadget: function: Add Generic USB Display support

Re: [-next PATCH 0/4] sysfs and DEVICE_ATTR_

[PATCH] drm/tilcdc: add missing clk_put in tilcdc_unload()

[PATCH] regulator: stub out devm_regulator_get_exclusive

[PATCH] regulator: stub out devm_regulator_get_exclusive

[PATCH] regulator: stub out devm_regulator_get_exclusive

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

possible deadlock on nouveau

[PATCH] drm/tilcdc increase allowable supported resolution

[PATCH] drm/tilcdc: restore correct display mode and contents on pm resume

[PATCH] drm/tilcdc increase allowable supported resolution

[PATCH] drm/tilcdc: restore correct display mode and contents on pm resume

Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks

Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks

Re: [PATCH 37/51] DMA-API: usb: use new dma_coerce_mask_and_coherent()

Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()

i915 not working on Dell e6410

i915 not working on Dell e6410

i915 not working on Dell e6410

Re: i915 not working on Dell e6410

Re: [PATCH 1/2] drm: fixup headers_check

Re: [PATCH 1/2] drm: fixup headers_check

Re: [PATCH 1/2] drm: fixup headers_check

Re: [PATCH 1/2] drm: fixup headers_check

[PATCH 1/2] drm: fixup headers_check

[PATCH 1/2] drm: fixup headers_check

[PATCH 1/2] drm: fixup headers_check

[PATCH 1/2] drm: fixup headers_check

[PATCH 1/2] drm: fixup headers_check

[PATCH 1/2] drm: fixup headers_check

36 matches

Site Navigation

Mail list logo

Footer information