Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Thu, Jan 02, 2014 at 07:10:55PM -0800, Greg Kroah-Hartman wrote:
On Thu, Jan 02, 2014 at 09:27:58PM +, Russell King wrote:
Subsystems such as ALSA, DRM and others require a single card-level
device structure to represent a subsystem. However, firmware tends to
describe the individual devices and the connections between them.
Therefore, we need a way to gather up the individual component devices
together, and indicate when we have all the component devices.
We do this in DT by providing a superdevice node which specifies
the components, eg:
imx-drm {
compatible = fsl,drm;
crtcs = ipu1;
connectors = hdmi;
};
The superdevice is declared into the component support, along with the
subcomponents. The superdevice receives callbacks to locate the
subcomponents, and identify when all components are present. At this
point, we bind the superdevice, which causes the appropriate subsystem
to be initialised in the conventional way.
When any of the components or superdevice are removed from the system,
we unbind the superdevice, thereby taking the subsystem down.
This sounds a lot like the containers code that Rafael just submitted
and I acked for 3.14. Look at the lkml post:
Subject: [PATCH 2/2] ACPI / hotplug / driver core: Handle containers in
a special way
Message-ID: 1991202.gilw172...@vostro.rjw.lan
And see if that could possibly be used instead?
That's really disappointing bcause I've put a hell of a lot of work into
this over the last few months, and if that's true it's all just been a
total waste of my time. Okay, lesson learned - don't spend any time
trying to fix other people's problems after discussing them at
kernel-summit.
In any case, the above message ID doesn't give me access to this containers
code to look at to even evaluate whether it can be used for this - it just
gives two patches for ACPI specific patches but not the core stuff.
http://www.spinics.net/lists/linux-acpi/msg48101.html
http://www.spinics.net/lists/linux-acpi/msg48102.html
Please provide a better reference to the code you're referring to.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was up to 13.2Mbit.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Friday, January 03, 2014 11:00:30 AM Russell King - ARM Linux wrote:
On Thu, Jan 02, 2014 at 07:10:55PM -0800, Greg Kroah-Hartman wrote:
On Thu, Jan 02, 2014 at 09:27:58PM +, Russell King wrote:
Subsystems such as ALSA, DRM and others require a single card-level
device structure to represent a subsystem. However, firmware tends to
describe the individual devices and the connections between them.
Therefore, we need a way to gather up the individual component devices
together, and indicate when we have all the component devices.
We do this in DT by providing a superdevice node which specifies
the components, eg:
imx-drm {
compatible = fsl,drm;
crtcs = ipu1;
connectors = hdmi;
};
The superdevice is declared into the component support, along with the
subcomponents. The superdevice receives callbacks to locate the
subcomponents, and identify when all components are present. At this
point, we bind the superdevice, which causes the appropriate subsystem
to be initialised in the conventional way.
When any of the components or superdevice are removed from the system,
we unbind the superdevice, thereby taking the subsystem down.
This sounds a lot like the containers code that Rafael just submitted
and I acked for 3.14. Look at the lkml post:
Subject: [PATCH 2/2] ACPI / hotplug / driver core: Handle containers in
a special way
Message-ID: 1991202.gilw172...@vostro.rjw.lan
And see if that could possibly be used instead?
That's really disappointing bcause I've put a hell of a lot of work into
this over the last few months, and if that's true it's all just been a
total waste of my time. Okay, lesson learned - don't spend any time
trying to fix other people's problems after discussing them at
kernel-summit.
Well, I didn't know that you were doing this work and my patch is to address
a specific problem that people are seeing in testing. Also, the generic
containers part in it is very simple and it might be possible to integrate it
with your code, this way or another. In fact, the only only thing I need from
containers at the moment is the online/offline functionality.
In any case, the above message ID doesn't give me access to this containers
code to look at to even evaluate whether it can be used for this - it just
gives two patches for ACPI specific patches but not the core stuff.
http://www.spinics.net/lists/linux-acpi/msg48101.html
http://www.spinics.net/lists/linux-acpi/msg48102.html
Please provide a better reference to the code you're referring to.
You can use the linux-next branch of the linux-pm.git tree at the moment or I
can set up a separate branch for that if that helps. The two patches above
depend on some earlier material I've gueued up for 3.14, but it's mostly
ACPI hotplug code.
Thanks,
Rafael
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] Staging: rtl8188eu: Fixed coding style issues
Thank you for your feedback. I'm still figuring stuff out. Submitting patches to the kernel has been my new year's resolution. Regards, Tim 2014/1/3 Dan Carpenter dan.carpen...@oracle.com: On Fri, Jan 03, 2014 at 12:22:59AM +0100, Tim Jester-Pfadt wrote: Fixed indentation coding style issues on rtw_io.c Signed-off-by: Tim Jester-Pfadt t...@gmx.de --- Next time, if you do a v2 patch please put a note here under the --- line what changed between the previous one and this one. 2: changed blah blah blah. drivers/staging/rtl8188eu/core/rtw_io.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
I want to transfer an abandoned
Hi friend I am a banker in IDB BANK. I want to transfer an abandoned USD5. 5Million to your Bank account. 40/percent will be your share. No risk involved but keep it as secret.Contact me for more details.Please I will like you to reply. thank you,mr.sinzogan chabi. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Fri, Jan 03, 2014 at 12:58:16PM +0100, Rafael J. Wysocki wrote:
On Friday, January 03, 2014 11:00:30 AM Russell King - ARM Linux wrote:
On Thu, Jan 02, 2014 at 07:10:55PM -0800, Greg Kroah-Hartman wrote:
On Thu, Jan 02, 2014 at 09:27:58PM +, Russell King wrote:
Subsystems such as ALSA, DRM and others require a single card-level
device structure to represent a subsystem. However, firmware tends to
describe the individual devices and the connections between them.
Therefore, we need a way to gather up the individual component devices
together, and indicate when we have all the component devices.
We do this in DT by providing a superdevice node which specifies
the components, eg:
imx-drm {
compatible = fsl,drm;
crtcs = ipu1;
connectors = hdmi;
};
The superdevice is declared into the component support, along with the
subcomponents. The superdevice receives callbacks to locate the
subcomponents, and identify when all components are present. At this
point, we bind the superdevice, which causes the appropriate subsystem
to be initialised in the conventional way.
When any of the components or superdevice are removed from the system,
we unbind the superdevice, thereby taking the subsystem down.
This sounds a lot like the containers code that Rafael just submitted
and I acked for 3.14. Look at the lkml post:
Subject: [PATCH 2/2] ACPI / hotplug / driver core: Handle containers in
a special way
Message-ID: 1991202.gilw172...@vostro.rjw.lan
And see if that could possibly be used instead?
That's really disappointing bcause I've put a hell of a lot of work into
this over the last few months, and if that's true it's all just been a
total waste of my time. Okay, lesson learned - don't spend any time
trying to fix other people's problems after discussing them at
kernel-summit.
Well, I didn't know that you were doing this work and my patch is to address
a specific problem that people are seeing in testing. Also, the generic
containers part in it is very simple and it might be possible to integrate it
with your code, this way or another. In fact, the only only thing I need from
containers at the moment is the online/offline functionality.
We had a session at kernel summit chaired by David Airlie to discuss
various issues associated with DRM which included the problems of
componentised devices registering into card-based subsystems. There
were quite a number of attendees to that session.
It is in that session that I said I would work on this, specifically
with the aim of getting imx-drm out of drivers/staging.
In any case, the above message ID doesn't give me access to this containers
code to look at to even evaluate whether it can be used for this - it just
gives two patches for ACPI specific patches but not the core stuff.
http://www.spinics.net/lists/linux-acpi/msg48101.html
http://www.spinics.net/lists/linux-acpi/msg48102.html
Please provide a better reference to the code you're referring to.
You can use the linux-next branch of the linux-pm.git tree at the moment or I
can set up a separate branch for that if that helps. The two patches above
depend on some earlier material I've gueued up for 3.14, but it's mostly
ACPI hotplug code.
I'm not sure what I'm looking for. I've tried looking at the results of
searching your linux-next branch for container but I don't see
anything implementing similar functionality to the patch I've sent.
https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-nextqt=grepq=container
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was up to 13.2Mbit.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Friday, January 03, 2014 12:18:13 PM Russell King - ARM Linux wrote:
On Fri, Jan 03, 2014 at 12:58:16PM +0100, Rafael J. Wysocki wrote:
On Friday, January 03, 2014 11:00:30 AM Russell King - ARM Linux wrote:
On Thu, Jan 02, 2014 at 07:10:55PM -0800, Greg Kroah-Hartman wrote:
On Thu, Jan 02, 2014 at 09:27:58PM +, Russell King wrote:
Subsystems such as ALSA, DRM and others require a single card-level
device structure to represent a subsystem. However, firmware tends to
describe the individual devices and the connections between them.
Therefore, we need a way to gather up the individual component devices
together, and indicate when we have all the component devices.
We do this in DT by providing a superdevice node which specifies
the components, eg:
imx-drm {
compatible = fsl,drm;
crtcs = ipu1;
connectors = hdmi;
};
The superdevice is declared into the component support, along with the
subcomponents. The superdevice receives callbacks to locate the
subcomponents, and identify when all components are present. At this
point, we bind the superdevice, which causes the appropriate subsystem
to be initialised in the conventional way.
When any of the components or superdevice are removed from the system,
we unbind the superdevice, thereby taking the subsystem down.
This sounds a lot like the containers code that Rafael just submitted
and I acked for 3.14. Look at the lkml post:
Subject: [PATCH 2/2] ACPI / hotplug / driver core: Handle
containers in a special way
Message-ID: 1991202.gilw172...@vostro.rjw.lan
And see if that could possibly be used instead?
That's really disappointing bcause I've put a hell of a lot of work into
this over the last few months, and if that's true it's all just been a
total waste of my time. Okay, lesson learned - don't spend any time
trying to fix other people's problems after discussing them at
kernel-summit.
Well, I didn't know that you were doing this work and my patch is to address
a specific problem that people are seeing in testing. Also, the generic
containers part in it is very simple and it might be possible to integrate
it
with your code, this way or another. In fact, the only only thing I need
from
containers at the moment is the online/offline functionality.
We had a session at kernel summit chaired by David Airlie to discuss
various issues associated with DRM which included the problems of
componentised devices registering into card-based subsystems. There
were quite a number of attendees to that session.
Yeah, I was there too.
It is in that session that I said I would work on this, specifically
with the aim of getting imx-drm out of drivers/staging.
OK, but that's not directly related to what I did with containers.
In any case, the above message ID doesn't give me access to this
containers
code to look at to even evaluate whether it can be used for this - it just
gives two patches for ACPI specific patches but not the core stuff.
http://www.spinics.net/lists/linux-acpi/msg48101.html
http://www.spinics.net/lists/linux-acpi/msg48102.html
Please provide a better reference to the code you're referring to.
You can use the linux-next branch of the linux-pm.git tree at the moment or
I
can set up a separate branch for that if that helps. The two patches above
depend on some earlier material I've gueued up for 3.14, but it's mostly
ACPI hotplug code.
I'm not sure what I'm looking for. I've tried looking at the results of
searching your linux-next branch for container but I don't see
anything implementing similar functionality to the patch I've sent.
https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-nextqt=grepq=container
I've just set up the acpi-hotplug branch in linux-pm.git (because I often
rebase the linux-next one).
The only commit in that branch you need to look at is this one:
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=acpi-hotplugid=caa73ea158de9419f08e456f2716c71d1f06012a
but quite frankly I'm not sure how it is related to your work. :-)
Thanks,
Rafael
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] Staging: rtl8188eu: Fixed coding style issues
On Fri, 2014-01-03 at 00:22 +0100, Tim Jester-Pfadt wrote:
Fixed indentation coding style issues on rtw_io.c
[]
diff --git a/drivers/staging/rtl8188eu/core/rtw_io.c
b/drivers/staging/rtl8188eu/core/rtw_io.c
[]
@@ -205,9 +205,9 @@ void _rtw_read_mem(struct adapter *adapter, u32 addr, u32
cnt, u8 *pmem)
_func_enter_;
if (adapter-bDriverStopped || adapter-bSurpriseRemoved) {
- RT_TRACE(_module_rtl871x_io_c_, _drv_info_,
- (rtw_read_mem:bDriverStopped(%d) OR
bSurpriseRemoved(%d),
- adapter-bDriverStopped, adapter-bSurpriseRemoved));
+ RT_TRACE(_module_rtl871x_io_c_, _drv_info_,
+ (rtw_read_mem:bDriverStopped(%d) OR
bSurpriseRemoved(%d),
+ adapter-bDriverStopped, adapter-bSurpriseRemoved));
Be nice to remove the unnecessary parentheses on all of these too
RT_TRACE(_module_rtl871x_io_c_, _drv_info_,
rtw_read_mem:bDriverStopped(%d) OR
bSurpriseRemoved(%d),
adapter-bDriverStopped, adapter-bSurpriseRemoved);
etc...
A few other things too:
o The _func_enter_ uses are unnecessary and could/should
be removed. There's a standard function tracing capability.
o The RT_TRACE uses that embed a function name could/should use
%s:, __func__
o The RT_TRACE macro doesn't add a terminating newline and these
uses should have them.
RT_TRACE(_module_rtl871x_io_c_, _drv_info_,
%s:bDriverStopped(%d) OR bSurpriseRemoved(%d)\n,
__func__, adapter-bDriverStopped,
adapter-bSurpriseRemoved);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Fri, Jan 03, 2014 at 02:24:26PM +0100, Rafael J. Wysocki wrote: On Friday, January 03, 2014 12:18:13 PM Russell King - ARM Linux wrote: I'm not sure what I'm looking for. I've tried looking at the results of searching your linux-next branch for container but I don't see anything implementing similar functionality to the patch I've sent. https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-nextqt=grepq=container I've just set up the acpi-hotplug branch in linux-pm.git (because I often rebase the linux-next one). The only commit in that branch you need to look at is this one: http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=acpi-hotplugid=caa73ea158de9419f08e456f2716c71d1f06012a but quite frankly I'm not sure how it is related to your work. :-) Yes, I'm coming to that conclusion as well. It looks like your containers aren't about collecting up several individual component devices into one super-device and probing the appropriate subsystem when all components are known. Confused why Greg is pointing me at your patches. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 21/46] drm: provide a helper for the encoder possible_crtcs mask
On Fri, Jan 03, 2014 at 05:05:46PM +0100, David Herrmann wrote: Hi On Thu, Jan 2, 2014 at 10:27 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: The encoder possible_crtcs mask identifies which CRTCs can be bound to a particular encoder. Each bit from bit 0 defines an index in the list of CRTCs held in the DRM mode_config crtc_list. Rather than having drivers trying to track the position of their CRTCs in the list, expose the code which already exists for calculating the appropriate mask bit for a CRTC. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/gpu/drm/drm_crtc_helper.c | 39 include/drm/drm_crtc_helper.h |1 + 2 files changed, 27 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 01361aba033b..10708c248196 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -325,6 +325,29 @@ void drm_helper_disable_unused_functions(struct drm_device *dev) EXPORT_SYMBOL(drm_helper_disable_unused_functions); /** + * drm_helper_crtc_possible_mask - find the mask of a registered CRTC + * @crtc: crtc to find mask for + * + * Given a registered CRTC, return the mask bit of that CRTC for an + * encoder's possible_crtcs field. I think this is a nice cleanup which we could pick up right away. Most drivers can be simplified by using this. Only the name is misleading, imo, I'd use something like drm_helper_crtc_to_mask(). I'm not so sure - since the only place this mask gets used is with the possible_crtcs field. It's got nothing to do with the possible_clones field as that isn't a mask of CRTCs. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 21/46] drm: provide a helper for the encoder possible_crtcs mask
Hi
On Thu, Jan 2, 2014 at 10:27 PM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
The encoder possible_crtcs mask identifies which CRTCs can be bound to
a particular encoder. Each bit from bit 0 defines an index in the list
of CRTCs held in the DRM mode_config crtc_list. Rather than having
drivers trying to track the position of their CRTCs in the list, expose
the code which already exists for calculating the appropriate mask bit
for a CRTC.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/gpu/drm/drm_crtc_helper.c | 39
include/drm/drm_crtc_helper.h |1 +
2 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 01361aba033b..10708c248196 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -325,6 +325,29 @@ void drm_helper_disable_unused_functions(struct
drm_device *dev)
EXPORT_SYMBOL(drm_helper_disable_unused_functions);
/**
+ * drm_helper_crtc_possible_mask - find the mask of a registered CRTC
+ * @crtc: crtc to find mask for
+ *
+ * Given a registered CRTC, return the mask bit of that CRTC for an
+ * encoder's possible_crtcs field.
I think this is a nice cleanup which we could pick up right away. Most
drivers can be simplified by using this. Only the name is misleading,
imo, I'd use something like drm_helper_crtc_to_mask(). Anyhow, not my
call so:
Reviewed-by: David Herrmann dh.herrm...@gmail.com
Thanks
David
+ */
+uint32_t drm_helper_crtc_possible_mask(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_crtc *tmp;
+ uint32_t crtc_mask = 1;
+
+ list_for_each_entry(tmp, dev-mode_config.crtc_list, head) {
+ if (tmp == crtc)
+ return crtc_mask;
+ crtc_mask = 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_helper_crtc_possible_mask);
+
+/**
* drm_encoder_crtc_ok - can a given crtc drive a given encoder?
* @encoder: encoder to test
* @crtc: crtc to test
@@ -334,23 +357,13 @@ EXPORT_SYMBOL(drm_helper_disable_unused_functions);
static bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
struct drm_crtc *crtc)
{
- struct drm_device *dev;
- struct drm_crtc *tmp;
- int crtc_mask = 1;
+ uint32_t crtc_mask;
WARN(!crtc, checking null crtc?\n);
- dev = crtc-dev;
-
- list_for_each_entry(tmp, dev-mode_config.crtc_list, head) {
- if (tmp == crtc)
- break;
- crtc_mask = 1;
- }
+ crtc_mask = drm_helper_crtc_possible_mask(crtc);
- if (encoder-possible_crtcs crtc_mask)
- return true;
- return false;
+ return !!(encoder-possible_crtcs crtc_mask);
}
/*
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index ef6ad3a8e58e..21b9f47dd88c 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -127,6 +127,7 @@ struct drm_connector_helper_funcs {
extern int drm_helper_probe_single_connector_modes(struct drm_connector
*connector, uint32_t maxX, uint32_t maxY);
extern void drm_helper_disable_unused_functions(struct drm_device *dev);
+extern uint32_t drm_helper_crtc_possible_mask(struct drm_crtc *crtc);
extern int drm_crtc_helper_set_config(struct drm_mode_set *set);
extern bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
struct drm_display_mode *mode,
--
1.7.4.4
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 21/46] drm: provide a helper for the encoder possible_crtcs mask
On Fri, Jan 03, 2014 at 05:26:14PM +0100, David Herrmann wrote: Hi On Fri, Jan 3, 2014 at 5:13 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: I'm not so sure - since the only place this mask gets used is with the possible_crtcs field. It's got nothing to do with the possible_clones field as that isn't a mask of CRTCs. ... possible_clones is about encoders, you're right, I missed that. So you can carry it in your series just fine. Thanks for confirming that - it's something which imx-drm seemed to get wrong as put the same value into possible_clones as it did for possible_crtcs. I was fairly certain that was buggy. :) -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
Hi Russell,
I've tested this series on a BD-SL (SabreLite) with HDMI. Right now
the HPD signal doesn't seem to work, but after overwriting the
connection check, I got a stable and correct picture on the monitor:
arch/arm/boot/dts/imx6q-sabrelite.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts
b/arch/arm/boot/dts/imx6q-sabrelite.dts
index f004913..cf9b3f5 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -50,6 +50,12 @@
};
};
+ imx-drm {
+ compatible = fsl,imx-drm;
+ crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
+ connectors = hdmi;
+ };
+
sound {
compatible = fsl,imx6q-sabrelite-sgtl5000,
fsl,imx-audio-sgtl5000;
@@ -93,6 +99,12 @@
status = okay;
};
+hdmi {
+ status = okay;
+ ddc = i2c2;
+ crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
+};
+
i2c1 {
status = okay;
clock-frequency = 10;
@@ -108,6 +120,13 @@
};
};
+i2c2 {
+ status = okay;
+ clock-frequency = 10;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_i2c2_2;
+};
+
iomuxc {
pinctrl-names = default;
pinctrl-0 = pinctrl_hog;
--
1.8.5.1
Am Donnerstag, den 02.01.2014, 21:28 + schrieb Russell King:
Use the componentised device support for imx-drm. This requires all
the sub-components and the master device to register with the component
device support.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/boot/dts/imx51-babbage.dts| 10 ++-
arch/arm/boot/dts/imx53-m53evk.dts |8 ++-
arch/arm/boot/dts/imx53-mba53.dts |6 ++
arch/arm/boot/dts/imx53-qsb.dts|8 ++-
arch/arm/boot/dts/imx6qdl-sabresd.dtsi |6 ++
drivers/staging/imx-drm/imx-drm-core.c | 105 ++-
drivers/staging/imx-drm/imx-ldb.c | 40 ---
drivers/staging/imx-drm/imx-tve.c | 63 +++--
drivers/staging/imx-drm/ipuv3-crtc.c | 46 +
drivers/staging/imx-drm/parallel-display.c | 30 ++--
10 files changed, 242 insertions(+), 80 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-babbage.dts
b/arch/arm/boot/dts/imx51-babbage.dts
index be1407cf5abd..6ff15a0eacb3 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -21,7 +21,7 @@
reg = 0x9000 0x2000;
};
- display@di0 {
+ display0: display@di0 {
compatible = fsl,imx-parallel-display;
crtcs = ipu 0;
[...]
Before moving imx-drm out of staging, I'd like to get rid of the
unfortunate 'crtcs' property. I'd rather prefer the components to be
connected with a device tree graph. I'm not quite sure if the DI0/1
should have their own device tree node inside the IPU node or if they
should just appear directly as two of four ports of the IPU (the other
two being CSI0/1). In the latter case, for example:
arch/arm/boot/dts/imx6q.dtsi | 32 ++--
arch/arm/boot/dts/imx6qdl.dtsi | 33 -
drivers/staging/imx-drm/imx-drm-core.c | 44
3 files changed, 94 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 187fe33..93f4721 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -132,13 +132,30 @@
};
ipu2: ipu@0280 {
- #crtc-cells = 1;
+ #address-cells = 1;
+ #size-cells = 0;
compatible = fsl,imx6q-ipu;
reg = 0x0280 0x40;
interrupts = 0 8 0x4 0 7 0x4;
clocks = clks 133, clks 134, clks 137;
clock-names = bus, di0, di1;
resets = src 4;
+
+ port@2 {
+ reg = 2;
+
+ ipu2_di0_hdmi: endpoint {
+ remote-endpoint = hdmi_mux_2;
+ };
+ };
+
+ port@3 {
+ reg = 3;
+
+ ipu2_di1_hdmi: endpoint {
+ remote-endpoint = hdmi_mux_3;
+ };
+ };
};
};
};
@@ -162,5 +179,16 @@
hdmi {
compatible = fsl,imx6q-hdmi;
- crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
+
+ port@2 {
+ hdmi_mux_2: endpoint {
+ remote-endpoint = ipu2_di0_hdmi;
+ };
+ };
+
+ port@3 {
+
Re: [RFC PATCH 0/5] Move IPUv3 core out of staging, add CSI support
Am Freitag, den 20.12.2013, 11:12 -0800 schrieb Greg Kroah-Hartman: On Fri, Dec 20, 2013 at 06:52:41PM +0100, Philipp Zabel wrote: Hi, this is mostly about the first patch, which moves the IPUv3 core code (drivers/staging/imx-drm/ipu-v3) to drivers/gpu. host1x, which serves a similar purpose, already sits there. The other four patches add the necessary code for CSI and SMFC handling, which is used by the V4L2 CSI capture driver. Currently this is based on Russell's patch [PATCH 62/64] imx-drm: pass an IPU ID to crtc and core I am aware that there are now quite a few other patches in the pipeline that touch drivers/staging/imx-drm/ipu-v3/*, so I am happy to rebase this (or them) as needed. I'd like to move the core code out of staging so that we can start submitting V4L2 code for video capture and scaling / colorspace conversion in parallel. I'd recommend doing the move (if the gpu/drm maintainer agrees) after 3.14-rc1 as then all of my pending patches would be applied and we would be synced up with everything. Ok. Once this core is moved, what is keeping the rest in staging and why isn't it moving out as well? Russell put a lot of work into fixing imx-drm issues, and I'd like to make the change to a common device tree binding before this leaves staging. regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
On Fri, Jan 03, 2014 at 05:48:57PM +0100, Philipp Zabel wrote: Hi Russell, I've tested this series on a BD-SL (SabreLite) with HDMI. Right now the HPD signal doesn't seem to work, but after overwriting the connection check, I got a stable and correct picture on the monitor: Hmm. Does this mean you're not getting any IRQs from the HDMI interface when you plug and unplug the monitor? 147:281 GIC 147 12.hdmi on turning the TV on: 147:282 GIC 147 12.hdmi on unplugging the HDMI cable: 147:283 GIC 147 12.hdmi on replugging the HDMI cable: 147:284 GIC 147 12.hdmi -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
Am Freitag, den 03.01.2014, 17:07 + schrieb Russell King - ARM Linux: On Fri, Jan 03, 2014 at 05:48:57PM +0100, Philipp Zabel wrote: Hi Russell, I've tested this series on a BD-SL (SabreLite) with HDMI. Right now the HPD signal doesn't seem to work, but after overwriting the connection check, I got a stable and correct picture on the monitor: Hmm. Does this mean you're not getting any IRQs from the HDMI interface when you plug and unplug the monitor? 147:281 GIC 147 12.hdmi on turning the TV on: 147:282 GIC 147 12.hdmi on unplugging the HDMI cable: 147:283 GIC 147 12.hdmi on replugging the HDMI cable: 147:284 GIC 147 12.hdmi Exactly. And while the RX_SENSE bits of HDMI_IH_PHY_STAT0 change when I (un)plug, the HPD bit stays zero. I'll check with other hardware. regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
On Fri, Jan 03, 2014 at 06:26:44PM +0100, Philipp Zabel wrote: Am Freitag, den 03.01.2014, 17:07 + schrieb Russell King - ARM Linux: On Fri, Jan 03, 2014 at 05:48:57PM +0100, Philipp Zabel wrote: Hi Russell, I've tested this series on a BD-SL (SabreLite) with HDMI. Right now the HPD signal doesn't seem to work, but after overwriting the connection check, I got a stable and correct picture on the monitor: Hmm. Does this mean you're not getting any IRQs from the HDMI interface when you plug and unplug the monitor? 147:281 GIC 147 12.hdmi on turning the TV on: 147:282 GIC 147 12.hdmi on unplugging the HDMI cable: 147:283 GIC 147 12.hdmi on replugging the HDMI cable: 147:284 GIC 147 12.hdmi Exactly. And while the RX_SENSE bits of HDMI_IH_PHY_STAT0 change when I (un)plug, the HPD bit stays zero. I'll check with other hardware. My guess would be that someone forgot to wire up the HPD line correctly. As ever, the documentation doesn't describe how this stuff works... -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
Hi Philipp, On 01/03/2014 10:26 AM, Philipp Zabel wrote: Am Freitag, den 03.01.2014, 17:07 + schrieb Russell King - ARM Linux: On Fri, Jan 03, 2014 at 05:48:57PM +0100, Philipp Zabel wrote: Hi Russell, I've tested this series on a BD-SL (SabreLite) with HDMI. Right now the HPD signal doesn't seem to work, but after overwriting the connection check, I got a stable and correct picture on the monitor: Hmm. Does this mean you're not getting any IRQs from the HDMI interface when you plug and unplug the monitor? 147:281 GIC 147 12.hdmi on turning the TV on: 147:282 GIC 147 12.hdmi on unplugging the HDMI cable: 147:283 GIC 147 12.hdmi on replugging the HDMI cable: 147:284 GIC 147 12.hdmi Exactly. And while the RX_SENSE bits of HDMI_IH_PHY_STAT0 change when I (un)plug, the HPD bit stays zero. I'll check with other hardware. This is an issue we've seen before. The SABRE Lite board has a voltage divider on the HPD pins and some monitors (esp. DVI monitors) either don't drive things high enough to assert HPD or bounce with connect/disconnect. We've instrumented our 3.0.35 kernels to use the RX_SENSE bits instead. Regards, Eric ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch] staging: vt6655: check too restrictive (off by one)
key_len == MAX_KEY_LEN is valid but we return an error.
Introduced-by: 6b7200fe0a59 ('Staging: vt6655: memory corruption in check in
wpa_set_wpadev()')
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/staging/vt6655/wpactl.c b/drivers/staging/vt6655/wpactl.c
index ee83704e4401..d43efb85f4d3 100644
--- a/drivers/staging/vt6655/wpactl.c
+++ b/drivers/staging/vt6655/wpactl.c
@@ -202,8 +202,8 @@ int wpa_set_keys(PSDevice pDevice, void *ctx, bool
fcpfkernel)
int uu, ii;
if (param-u.wpa_key.alg_name WPA_ALG_CCMP ||
- param-u.wpa_key.key_len = MAX_KEY_LEN ||
- param-u.wpa_key.seq_len = MAX_KEY_LEN)
+ param-u.wpa_key.key_len MAX_KEY_LEN ||
+ param-u.wpa_key.seq_len MAX_KEY_LEN)
return -EINVAL;
DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO param-u.wpa_key.alg_name = %d \n,
param-u.wpa_key.alg_name);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[patch] staging: vt6656: remove an unneeded NULL check
We dereference param-u.wpa_key.key on the next line so the check here is inconsistent. This is only called from iwctl_siwencodeext() and param-u.wpa_key.key is a valid pointer. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/staging/vt6656/wpactl.c b/drivers/staging/vt6656/wpactl.c index 003bd7c614e5..f4a8a5cb9feb 100644 --- a/drivers/staging/vt6656/wpactl.c +++ b/drivers/staging/vt6656/wpactl.c @@ -86,7 +86,7 @@ int wpa_set_keys(struct vnt_private *pDevice, void *ctx) return ret; } - if (param-u.wpa_key.key param-u.wpa_key.key_len sizeof(abyKey)) + if (param-u.wpa_key.key_len sizeof(abyKey)) return -EINVAL; memcpy(abyKey[0], param-u.wpa_key.key, param-u.wpa_key.key_len); ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 24/31] staging: r8188eu: Additional cleanup of include/odm.h
Fine, fine. I don't have strong feelings about this... regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
