Re: [PATCH] [media] stv090x: do not unlock unheld mutex in stv090x_sleep()
On 02/20/2013 10:58 AM, Manu Abraham wrote: Hi, On Wed, Feb 20, 2013 at 12:28 AM, Alexey Khoroshilov khoroshi...@ispras.ru wrote: goto err and goto err_gateoff before mutex_lock(state-internal-demod_lock) lead to unlock of unheld mutex in stv090x_sleep(). Out of curiosity, what happens when you try to unlock an unlocked mutex ? Regards, Manu Bad things can happen if someone else holds the mutex and it becomes unexpectedly unlocked. Also it can result that the next lock() operation leaves the mutex in unlocked state. The both cases can lead to data races with unpredictable consequences. -- Alexey Khoroshilov -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wrongly identified easycap em28xx
Theodore Kilgore kilg...@banach.math.auburn.edu wrote: On Tue, 19 Feb 2013, Mauro Carvalho Chehab wrote: Em Tue, 19 Feb 2013 20:45:21 +0100 Frank Sch?fer fschaefer@googlemail.com escreveu: Am 19.02.2013 19:53, schrieb Mauro Carvalho Chehab: Em Tue, 19 Feb 2013 19:45:29 +0100 Frank Sch?fer fschaefer@googlemail.com escreveu: I don't like the idea of merging those two entries. As far as I remember there are devices that works out of the box with EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break the driver for them. As described above, there is a good chance to break devices with both solutions. What's your suggestion ? ;-) As I said, just leave it as-is (documenting at web) That seems to be indeed the only 100%-regression-safe solution. But also _no_ solution for this device. A device which works only with a special module parameter passed on driver loading isn't much better than an unsupported device. That's not true. There are dozens of devices that only work with modprobe parameter (even ones with their own USB or PCI address). The thing is that crappy vendors don't provide any way for a driver to detect what's there, as their driver rely on some *.inf config file with those parameters hardcoded. We can't do any better than what's provided by the device. It comes down to the following question: Do we want to refuse fixing known/existing devices for the sake of avoiding regression for unknown devices which even might not exist ? ;-) HUH? As I said: there are devices that work with the other board entry. If you remove the other entry, _then_ you'll be breaking the driver. I have no strong and final opinion yet. Still hoping someone knows how the Empia driver handles these cases... What do you mean? The original driver? The parameters are hardcoded at the *.inf file. Once you get the driver, the *.inf file contains all the parameters for it to work there. If you have two empia devices with different models, you can only use the second one after removing the install for the first one. or to use the AC97 chip ID as a hint. This works fine for devices that don't come with Empiatech em202, but with something else, like the case of the Realtek chip found on this device. The reference design for sure uses em202. How could the AC97 chip ID help us in this situation ? As far as I understand, it doesn't matter which AC97 IC is used. They are all compatible and at least our driver uses the same code for all of them. The em28xx Kernel driver uses a hint code to try to identify the device model. That hint code is not perfect, but it is the better we can do. There are two hint codes there, currently: 1) device's eeprom hash, used when the device has an eeprom, but the USB ID is not unique; 2) I2C scan bus hash: sometimes, different devices use different I2C addresses. So even if you are are right and the Empia reference design uses an EMP202, EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other AC97-ICs, too. The vast majority of devices use emp202. There are very few ones using different models. The proposal here is to add a third hint code, that would distinguish the devices based on the ac97 ID. We should also expect manufacturers to switch between them whenever they want (e.g. because of price changes). Yes, and then we'll need other entries at the hint table. Regards Mauro I see the dilemma. Devices which are not uniquely identifiable. Mauro is right in pinpointing the problem, and he is also right that one can not expect the manufacturers to pay any attention. Mauro is also absolutely right that it is not good to break what works already for some people, hoping to please some others who are presently unhappy. A better solution needs to be found. Could I make a suggestion? Sometimes it is possible to find some undocumented way to identify uniquely which one of two devices you have. As an example, look in mr97310a.c, where there is a detection routine for several devices which all have the same USB vendor:product code but are different inside. Indeed, back when lots of those mr97310a cameras were on the market, the manufacturers were supposed to be sending out the cameras with the right windows driver. Except the situation was actually so bad that quite often some of the manufacturers were grabbing the wrong driver CD off the shelf and putting it with the wrong cameras! You can do a Google search for the Windows driver for some of those cameras and find web pages full of complaints from disgruntled users who got the wrong CD in the package with the camera, frantically looking for the right driver CD. It was that bad. Now to top that off, think of some poor guy having a Windows computer and wanting to have two cameras of the same brand and make, with identical cases on the outside,
Re: Wrongly identified easycap em28xx
Em Tue, 19 Feb 2013 23:09:16 -0600 (CST) Theodore Kilgore kilg...@banach.math.auburn.edu escreveu: On Tue, 19 Feb 2013, Mauro Carvalho Chehab wrote: Em Tue, 19 Feb 2013 20:45:21 +0100 Frank Sch?fer fschaefer@googlemail.com escreveu: Am 19.02.2013 19:53, schrieb Mauro Carvalho Chehab: Em Tue, 19 Feb 2013 19:45:29 +0100 Frank Sch?fer fschaefer@googlemail.com escreveu: I don't like the idea of merging those two entries. As far as I remember there are devices that works out of the box with EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break the driver for them. As described above, there is a good chance to break devices with both solutions. What's your suggestion ? ;-) As I said, just leave it as-is (documenting at web) That seems to be indeed the only 100%-regression-safe solution. But also _no_ solution for this device. A device which works only with a special module parameter passed on driver loading isn't much better than an unsupported device. That's not true. There are dozens of devices that only work with modprobe parameter (even ones with their own USB or PCI address). The thing is that crappy vendors don't provide any way for a driver to detect what's there, as their driver rely on some *.inf config file with those parameters hardcoded. We can't do any better than what's provided by the device. It comes down to the following question: Do we want to refuse fixing known/existing devices for the sake of avoiding regression for unknown devices which even might not exist ? ;-) HUH? As I said: there are devices that work with the other board entry. If you remove the other entry, _then_ you'll be breaking the driver. I have no strong and final opinion yet. Still hoping someone knows how the Empia driver handles these cases... What do you mean? The original driver? The parameters are hardcoded at the *.inf file. Once you get the driver, the *.inf file contains all the parameters for it to work there. If you have two empia devices with different models, you can only use the second one after removing the install for the first one. or to use the AC97 chip ID as a hint. This works fine for devices that don't come with Empiatech em202, but with something else, like the case of the Realtek chip found on this device. The reference design for sure uses em202. How could the AC97 chip ID help us in this situation ? As far as I understand, it doesn't matter which AC97 IC is used. They are all compatible and at least our driver uses the same code for all of them. The em28xx Kernel driver uses a hint code to try to identify the device model. That hint code is not perfect, but it is the better we can do. There are two hint codes there, currently: 1) device's eeprom hash, used when the device has an eeprom, but the USB ID is not unique; 2) I2C scan bus hash: sometimes, different devices use different I2C addresses. So even if you are are right and the Empia reference design uses an EMP202, EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other AC97-ICs, too. The vast majority of devices use emp202. There are very few ones using different models. The proposal here is to add a third hint code, that would distinguish the devices based on the ac97 ID. We should also expect manufacturers to switch between them whenever they want (e.g. because of price changes). Yes, and then we'll need other entries at the hint table. Regards Mauro I see the dilemma. Devices which are not uniquely identifiable. Mauro is right in pinpointing the problem, and he is also right that one can not expect the manufacturers to pay any attention. Mauro is also absolutely right that it is not good to break what works already for some people, hoping to please some others who are presently unhappy. A better solution needs to be found. Could I make a suggestion? Sometimes it is possible to find some undocumented way to identify uniquely which one of two devices you have. The hardware is identical, except for the audio decoder. Both devices have only 3 chips on it: the em2860 chip, an saa7113 video decoder and the ac97 audio mixer, that it is different on each device. One board comes with an ac97 chip ID=0x [1](emp202, found on the reference design and clones). The other one comes with an ac97 chip with ID=0x414c4761 (a Realtek ALC653, only found so far on EasyCap DC-60). Btw, the issue between them is because of the different mixers found: the mixer channel used by the DC-60 is different than the mixer channel used by the reference design. At the reference design, the audio channel is EM28XX_AMUX_VIDEO. At DC-60, it is EM28XX_AMUX_LINE_IN. I can't think on any other way do distinguish between them except by checking
RE: [PATCH v6 1/1] video: drm: exynos: Add display-timing node parsing using video helper function
-Original Message-
From: Vikas Sajjan [mailto:vikas.saj...@linaro.org]
Sent: Friday, February 15, 2013 3:43 PM
To: dri-de...@lists.freedesktop.org
Cc: linux-media@vger.kernel.org; kgene@samsung.com;
inki@samsung.com; l.kris...@samsung.com; patc...@linaro.org
Subject: [PATCH v6 1/1] video: drm: exynos: Add display-timing node
parsing using video helper function
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 37
++
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..8b2c0ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,7 +19,9 @@
#include linux/clk.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
+#include video/of_display_timing.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -877,16 +879,43 @@ static int fimd_probe(struct platform_device *pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ fbmode = pdata-panel.timing;
+ ret = of_get_fb_videomode(dev-of_node, fbmode,
+ OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode()\n
+ with return value: %d\n, ret);
+ return ret;
+ }
+
+ pctrl = devm_pinctrl_get_select_default(dev);
Why does it need pinctrl? and even though needed, I think this should be
separated into another one.
Thanks,
Inki Dae
+ if (IS_ERR_OR_NULL(pctrl)) {
+ DRM_ERROR(failed:
devm_pinctrl_get_select_default()\n
+ with return value: %d\n, PTR_RET(pctrl));
+ return PTR_RET(pctrl);
+ }
+
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 6/7] sound/soc/codecs: Convert SI476X codec to use regmap
On Mon, Feb 18, 2013 at 07:59:34PM -0800, Andrey Smirnov wrote: From: Andrey Smirnov andreysm@charmander.(none) The latest radio and MFD drivers for SI476X radio chips use regmap API to provide access to the registers and allow for caching of their Applied, thanks. Always use subject lines appropriate for the subsystem you're submitting against. signature.asc Description: Digital signature
Re: [PATCH v4 7/7] sound/soc/codecs: Cosmetic changes to SI476X codec driver
On Mon, Feb 18, 2013 at 07:59:35PM -0800, Andrey Smirnov wrote: - Add appropriate license header - Change email address in MODULE_AUTHOR - Remove trailing whitespaces Applied, thanks. Always use subject lines appropriate for the subsystem you're submitting against. signature.asc Description: Digital signature
Re: Wrongly identified easycap em28xx
Am 19.02.2013 23:42, schrieb Mauro Carvalho Chehab: Em Tue, 19 Feb 2013 23:14:38 +0100 Frank Schäfer fschaefer@googlemail.com escreveu: Am 19.02.2013 21:03, schrieb Mauro Carvalho Chehab: Em Tue, 19 Feb 2013 20:45:21 +0100 Frank Schäfer fschaefer@googlemail.com escreveu: It comes down to the following question: Do we want to refuse fixing known/existing devices for the sake of avoiding regression for unknown devices which even might not exist ? ;-) HUH? As I said: there are devices that work with the other board entry. If you remove the other entry, _then_ you'll be breaking the driver. Which devices _with_audio_support_ are working with EM2860_BOARD_SAA711X_REFERENCE_DESIGN ? AFAIK, the existence of such a device is pure theory at the moment. But the Easycap DC-60 is reality ! See the mailing lists archives. This driver is older than linux-media ML, and it used to have a separate em28xx mailing list in the past. Not sure if are there any mirror preserving the old logs for the em28xx ML, as this weren't hosted here. Poor argumentation. No evidences, just speculations. Please, don't pretend that you know all supported em28xx devices. Huh ??? I didn't do that. Instead I pointed out risk due to the fact that we do _not_ know all existing devices. It was actually _you_ who pretended to know such devices, but you failed to show us at least one of them. I have no strong and final opinion yet. Still hoping someone knows how the Empia driver handles these cases... What do you mean? The original driver? The parameters are hardcoded at the *.inf file. Once you get the driver, the *.inf file contains all the parameters for it to work there. If you have two empia devices with different models, you can only use the second one after removing the install for the first one. Are you sure about that ? That's the worst case. Yes, I'm pretty sure about that. or to use the AC97 chip ID as a hint. This works fine for devices that don't come with Empiatech em202, but with something else, like the case of the Realtek chip found on this device. The reference design for sure uses em202. How could the AC97 chip ID help us in this situation ? As far as I understand, it doesn't matter which AC97 IC is used. They are all compatible and at least our driver uses the same code for all of them. The em28xx Kernel driver uses a hint code to try to identify the device model. That hint code is not perfect, but it is the better we can do. There are two hint codes there, currently: 1) device's eeprom hash, used when the device has an eeprom, but the USB ID is not unique; 2) I2C scan bus hash: sometimes, different devices use different I2C addresses. ??? Again, how can the AC97 chip ID help us in this situation ? You just described the current board hint mechanism which clearly fails in this case. So even if you are are right and the Empia reference design uses an EMP202, EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other AC97-ICs, too. The vast majority of devices use emp202. There are very few ones using different models. The proposal here is to add a third hint code, that would distinguish the devices based on the ac97 ID. I already explained why this is a potential source for regressions, too. Yes, that may mean that other devices will need other entries, if are out there any device that looks like the reference design. So regressions are acceptable for you ? Yet, such device IS NOT the reference design, as it is very doubtful that Empia would be shipping their reference design with an AC97 chip manufactured by another vendor. Hmm... you seem to make a lot of assumptions about board EM2860_BOARD_SAA711X_REFERENCE_DESIGN... Are you aware that it was called EM2860_BOARD_POINTNIX_INTRAORAL_CAMERA before commit 3ed58baf ? According to the commit message it seems like it has been renamed just because a second device appeared. The commit message also mentions that both devices known at this time didn't have (real) audio support, which is the reason why there is no amux defined for the inputs. So the audio configuration of this board is EM28XX_AMUX_VIDEO likely just because there is no EM28XX_AMUX_NONE and noone ever tested it. Why are you sure that this configuration matches the official Empia reference board design (including the audio config) ? Do you have any information from Empia about that ? The second question is: do you think we can assume that the majority of the devices with generic USB IDs are following the reference design ? It should be easy to find out if the Easycap DC-60 follows the Empia reference design by testing if it works with the generic Empia Windows driver (http://home.eeti.com.tw/web20/eg/IC_support.htm). Regards, Frank There are, however, lots of device that just gets the Empia reference design as-is (the same applies to other vendors) and only designs a box with their logo. This is specially true for
Re: Wrongly identified easycap em28xx
Am 20.02.2013 06:09, schrieb Theodore Kilgore: On Tue, 19 Feb 2013, Mauro Carvalho Chehab wrote: Em Tue, 19 Feb 2013 20:45:21 +0100 Frank Sch?fer fschaefer@googlemail.com escreveu: Am 19.02.2013 19:53, schrieb Mauro Carvalho Chehab: Em Tue, 19 Feb 2013 19:45:29 +0100 Frank Sch?fer fschaefer@googlemail.com escreveu: I don't like the idea of merging those two entries. As far as I remember there are devices that works out of the box with EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break the driver for them. As described above, there is a good chance to break devices with both solutions. What's your suggestion ? ;-) As I said, just leave it as-is (documenting at web) That seems to be indeed the only 100%-regression-safe solution. But also _no_ solution for this device. A device which works only with a special module parameter passed on driver loading isn't much better than an unsupported device. That's not true. There are dozens of devices that only work with modprobe parameter (even ones with their own USB or PCI address). The thing is that crappy vendors don't provide any way for a driver to detect what's there, as their driver rely on some *.inf config file with those parameters hardcoded. We can't do any better than what's provided by the device. It comes down to the following question: Do we want to refuse fixing known/existing devices for the sake of avoiding regression for unknown devices which even might not exist ? ;-) HUH? As I said: there are devices that work with the other board entry. If you remove the other entry, _then_ you'll be breaking the driver. I have no strong and final opinion yet. Still hoping someone knows how the Empia driver handles these cases... What do you mean? The original driver? The parameters are hardcoded at the *.inf file. Once you get the driver, the *.inf file contains all the parameters for it to work there. If you have two empia devices with different models, you can only use the second one after removing the install for the first one. or to use the AC97 chip ID as a hint. This works fine for devices that don't come with Empiatech em202, but with something else, like the case of the Realtek chip found on this device. The reference design for sure uses em202. How could the AC97 chip ID help us in this situation ? As far as I understand, it doesn't matter which AC97 IC is used. They are all compatible and at least our driver uses the same code for all of them. The em28xx Kernel driver uses a hint code to try to identify the device model. That hint code is not perfect, but it is the better we can do. There are two hint codes there, currently: 1) device's eeprom hash, used when the device has an eeprom, but the USB ID is not unique; 2) I2C scan bus hash: sometimes, different devices use different I2C addresses. So even if you are are right and the Empia reference design uses an EMP202, EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other AC97-ICs, too. The vast majority of devices use emp202. There are very few ones using different models. The proposal here is to add a third hint code, that would distinguish the devices based on the ac97 ID. We should also expect manufacturers to switch between them whenever they want (e.g. because of price changes). Yes, and then we'll need other entries at the hint table. Regards Mauro I see the dilemma. Devices which are not uniquely identifiable. Mauro is right in pinpointing the problem, To be honest, it was _me_ who pointed out the dilemma here. and he is also right that one can not expect the manufacturers to pay any attention. Mauro is also absolutely right that it is not good to break what works already for some people, hoping to please some others who are presently unhappy. We all agree in this point (although it's actually the other way around in this case - we would _verifiably_ fix the Easycap device and _might_ break others). It's just as you said a few lines above - it's a dilemma. And at the moment, it seems the only way to make sure we don't cause regressions is to do nothing (= use module parameters) A better solution needs to be found. That's what this discussion is about. ;-) Could I make a suggestion? Sometimes it is possible to find some undocumented way to identify uniquely which one of two devices you have. As an example, look in mr97310a.c, where there is a detection routine for several devices which all have the same USB vendor:product code but are different inside. Indeed, back when lots of those mr97310a cameras were on the market, the manufacturers were supposed to be sending out the cameras with the right windows driver. Except the situation was actually so bad that quite often some of the manufacturers were grabbing the wrong driver CD off the shelf and putting it with the wrong cameras! You can do a Google search for the Windows driver for
Re: Wrongly identified easycap em28xx
snip Am 20.02.2013 11:51, schrieb Mauro Carvalho Chehab: Em Tue, 19 Feb 2013 23:09:16 -0600 (CST) Theodore Kilgore kilg...@banach.math.auburn.edu escreveu: On Tue, 19 Feb 2013, Mauro Carvalho Chehab wrote: So even if you are are right and the Empia reference design uses an EMP202, EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other AC97-ICs, too. The vast majority of devices use emp202. There are very few ones using different models. The proposal here is to add a third hint code, that would distinguish the devices based on the ac97 ID. We should also expect manufacturers to switch between them whenever they want (e.g. because of price changes). Yes, and then we'll need other entries at the hint table. Regards Mauro I see the dilemma. Devices which are not uniquely identifiable. Mauro is right in pinpointing the problem, and he is also right that one can not expect the manufacturers to pay any attention. Mauro is also absolutely right that it is not good to break what works already for some people, hoping to please some others who are presently unhappy. A better solution needs to be found. Could I make a suggestion? Sometimes it is possible to find some undocumented way to identify uniquely which one of two devices you have. The hardware is identical, except for the audio decoder. Both devices have only 3 chips on it: the em2860 chip, an saa7113 video decoder and the ac97 audio mixer, that it is different on each device. One board comes with an ac97 chip ID=0x [1](emp202, found on the reference design and clones). The other one comes with an ac97 chip with ID=0x414c4761 (a Realtek ALC653, only found so far on EasyCap DC-60). Btw, the issue between them is because of the different mixers found: the mixer channel used by the DC-60 is different than the mixer channel used by the reference design. At the reference design, the audio channel is EM28XX_AMUX_VIDEO. At DC-60, it is EM28XX_AMUX_LINE_IN. Now you got it. The relevant difference is the _channel_configuration_, not the used AC97 IC manufacturer+model. I can't think on any other way do distinguish between them except by checking if the audio decoder matches the expected one. Adding a logic for such check is simple enough, as the probing logic already contains the needed bits for it. I'm not convinced, for the following reasons: You can't infer from the usage of a particular AC97 IC how the device is wired internally / which channel configuration it uses. We also can't assume a fixed binding between a particular AC97 IC and a product/board. So _if_ we really decide to leave the conservative path and take the risk of regressions for the sake of fixing other devices, we should at least be sure that we fix more devices than we break. (Even then it still sucks !) Regards, Frank [1] There is a variant of emp202 at address 0x83847650. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Feb 20 19:00:22 CET 2013 git branch: for_v3.9 git hash: ed72d37a33fdf43dc47787fe220532cdec9da528 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8.03-marune linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: ERRORS linux-git-arm-omap: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-Module.symvers: ERRORS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/1] video: drm: exynos: Add display-timing node parsing using video helper function
Hi Mr. Inki Dae,
On 20 February 2013 16:45, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Vikas Sajjan [mailto:vikas.saj...@linaro.org]
Sent: Friday, February 15, 2013 3:43 PM
To: dri-de...@lists.freedesktop.org
Cc: linux-media@vger.kernel.org; kgene@samsung.com;
inki@samsung.com; l.kris...@samsung.com; patc...@linaro.org
Subject: [PATCH v6 1/1] video: drm: exynos: Add display-timing node
parsing using video helper function
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 37
++
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..8b2c0ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,7 +19,9 @@
#include linux/clk.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
+#include video/of_display_timing.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -877,16 +879,43 @@ static int fimd_probe(struct platform_device *pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ fbmode = pdata-panel.timing;
+ ret = of_get_fb_videomode(dev-of_node, fbmode,
+ OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode()\n
+ with return value: %d\n, ret);
+ return ret;
+ }
+
+ pctrl = devm_pinctrl_get_select_default(dev);
Why does it need pinctrl? and even though needed, I think this should be
separated into another one.
Will separate it out and send it in a separate patch.
Thanks,
Inki Dae
+ if (IS_ERR_OR_NULL(pctrl)) {
+ DRM_ERROR(failed:
devm_pinctrl_get_select_default()\n
+ with return value: %d\n, PTR_RET(pctrl));
+ return PTR_RET(pctrl);
+ }
+
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
--
1.7.9.5
--
Thanks and Regards
Vikas Sajjan
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 0/2] Add display-timing node parsing to exynos drm fimd
Add display-timing node parsing to drm fimd and depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. changes since v6: addressed comments from Inki Dae inki@samsung.com to separated out the pinctrl functionality and made a separate patch. changes since v5: - addressed comments from Inki Dae inki@samsung.com, to remove the allocation of 'fbmode' and replaced '-1'in of_get_fb_videomode(dev-of_node, fbmode, -1) with OF_USE_NATIVE_MODE. changes since v4: - addressed comments from Paul Menzel paulepan...@users.sourceforge.net, to modify the commit message changes since v3: - addressed comments from Sean Paul seanp...@chromium.org, to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev-dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma r.sh.o...@gmail.com) changes since v1: - addressed comments from Sean Paul seanp...@chromium.org Vikas Sajjan (2): video: drm: exynos: Add display-timing node parsing using video helper function video: drm: exynos: Add pinctrl support to fimd drivers/gpu/drm/exynos/exynos_drm_fimd.c | 36 ++ 1 file changed, 32 insertions(+), 4 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..f80cf68 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,7 @@
#include linux/of_device.h
#include linux/pm_runtime.h
+#include video/of_display_timing.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -877,16 +878,34 @@ static int fimd_probe(struct platform_device *pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ fbmode = pdata-panel.timing;
+ ret = of_get_fb_videomode(dev-of_node, fbmode,
+ OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode()\n
+ with return value: %d\n, ret);
+ return ret;
+ }
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 2/2] video: drm: exynos: Add pinctrl support to fimd
Adds support for pinctrl to drm fimd.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index f80cf68..878b134 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,7 @@
#include linux/clk.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
#include video/of_display_timing.h
#include video/samsung_fimd.h
@@ -879,6 +880,7 @@ static int fimd_probe(struct platform_device *pdev)
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
@@ -900,6 +902,13 @@ static int fimd_probe(struct platform_device *pdev)
with return value: %d\n, ret);
return ret;
}
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
+ DRM_ERROR(failed: devm_pinctrl_get_select_default()\n
+ with return value: %d\n, PTR_RET(pctrl));
+ return PTR_RET(pctrl);
+ }
+
} else {
pdata = pdev-dev.platform_data;
if (!pdata) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/1] video: drm: exynos: Add display-timing node parsing using video helper function
Hi,
On 02/15/2013 03:43 PM, Vikas Sajjan wrote:
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 37 ++
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..8b2c0ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,7 +19,9 @@
#include linux/clk.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
+#include video/of_display_timing.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -877,16 +879,43 @@ static int fimd_probe(struct platform_device *pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ fbmode = pdata-panel.timing;
+ ret = of_get_fb_videomode(dev-of_node, fbmode,
+ OF_USE_NATIVE_MODE);
fbmode variable can be substituted to pdata-panel.timing directly then
can remove fbmode variable.
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode()\n
+ with return value: %d\n, ret);
+ return ret;
+ }
+
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
It's enough to if (IS_ERR(pctrl)) {.
+ DRM_ERROR(failed: devm_pinctrl_get_select_default()\n
+ with return value: %d\n, PTR_RET(pctrl));
+ return PTR_RET(pctrl);
It's enough to return PTR_ERR(pctrl);
+ }
If this needs, parts for pinctrl should go to another patch.
+
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/2] Add display-timing node parsing to exynos drm fimd
Hi, Please refer my comments about v6 patch. On 02/21/2013 02:11 PM, Vikas Sajjan wrote: Add display-timing node parsing to drm fimd and depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. changes since v6: addressed comments from Inki Dae inki@samsung.com to separated out the pinctrl functionality and made a separate patch. changes since v5: - addressed comments from Inki Dae inki@samsung.com, to remove the allocation of 'fbmode' and replaced '-1'in of_get_fb_videomode(dev-of_node, fbmode, -1) with OF_USE_NATIVE_MODE. changes since v4: - addressed comments from Paul Menzel paulepan...@users.sourceforge.net, to modify the commit message changes since v3: - addressed comments from Sean Paul seanp...@chromium.org, to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev-dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma r.sh.o...@gmail.com) changes since v1: - addressed comments from Sean Paul seanp...@chromium.org Vikas Sajjan (2): video: drm: exynos: Add display-timing node parsing using video helper function video: drm: exynos: Add pinctrl support to fimd drivers/gpu/drm/exynos/exynos_drm_fimd.c | 36 ++ 1 file changed, 32 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/2] video: drm: exynos: Add pinctrl support to fimd
Hi,
On 02/21/2013 02:11 PM, Vikas Sajjan wrote:
Adds support for pinctrl to drm fimd.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index f80cf68..878b134 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,7 @@
#include linux/clk.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
#include video/of_display_timing.h
#include video/samsung_fimd.h
@@ -879,6 +880,7 @@ static int fimd_probe(struct platform_device *pdev)
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
@@ -900,6 +902,13 @@ static int fimd_probe(struct platform_device *pdev)
with return value: %d\n, ret);
return ret;
}
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
+ DRM_ERROR(failed: devm_pinctrl_get_select_default()\n
+ with return value: %d\n, PTR_RET(pctrl));
+ return PTR_RET(pctrl);
+ }
I think pinctrl isn't related with dt then it doesn't need to be in if
(pdev-dev.of_node).
+
Blank.
} else {
pdata = pdev-dev.platform_data;
if (!pdata) {
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/1] video: drm: exynos: Add display-timing node parsing using video helper function
Hi,
On 21 February 2013 12:25, Joonyoung Shim jy0922.s...@samsung.com wrote:
Hi,
On 02/15/2013 03:43 PM, Vikas Sajjan wrote:
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 37
++
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..8b2c0ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,7 +19,9 @@
#include linux/clk.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
+#include video/of_display_timing.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -877,16 +879,43 @@ static int fimd_probe(struct platform_device
*pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ fbmode = pdata-panel.timing;
+ ret = of_get_fb_videomode(dev-of_node, fbmode,
+ OF_USE_NATIVE_MODE);
fbmode variable can be substituted to pdata-panel.timing directly then can
remove fbmode variable.
this is can be done.
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode()\n
+ with return value: %d\n, ret);
+ return ret;
+ }
+
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
It's enough to if (IS_ERR(pctrl)) {.
what if it returns NULL?
+ DRM_ERROR(failed:
devm_pinctrl_get_select_default()\n
+ with return value: %d\n,
PTR_RET(pctrl));
+ return PTR_RET(pctrl);
It's enough to return PTR_ERR(pctrl);
ok.
+ }
If this needs, parts for pinctrl should go to another patch.
I have it as a separate patch already. [PATCH v7 2/2] video: drm:
exynos: Add pinctrl support to fimd
+
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
Thanks.
--
Thanks and Regards
Vikas Sajjan
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/1] video: drm: exynos: Add display-timing node parsing using video helper function
On 02/21/2013 04:12 PM, Vikas Sajjan wrote:
Hi,
On 21 February 2013 12:25, Joonyoung Shim jy0922.s...@samsung.com wrote:
Hi,
On 02/15/2013 03:43 PM, Vikas Sajjan wrote:
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 37
++
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..8b2c0ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,7 +19,9 @@
#include linux/clk.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
+#include video/of_display_timing.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -877,16 +879,43 @@ static int fimd_probe(struct platform_device
*pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ fbmode = pdata-panel.timing;
+ ret = of_get_fb_videomode(dev-of_node, fbmode,
+ OF_USE_NATIVE_MODE);
fbmode variable can be substituted to pdata-panel.timing directly then can
remove fbmode variable.
this is can be done.
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode()\n
+ with return value: %d\n, ret);
+ return ret;
+ }
+
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
It's enough to if (IS_ERR(pctrl)) {.
what if it returns NULL?
devm_pinctrl_get_select_default() never return NULL.
+ DRM_ERROR(failed:
devm_pinctrl_get_select_default()\n
+ with return value: %d\n,
PTR_RET(pctrl));
+ return PTR_RET(pctrl);
It's enough to return PTR_ERR(pctrl);
ok.
+ }
If this needs, parts for pinctrl should go to another patch.
I have it as a separate patch already. [PATCH v7 2/2] video: drm:
exynos: Add pinctrl support to fimd
+
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
